svn commit: r218277 - in stable/7/sys: kern sys
Andre Albsmeier
Andre.Albsmeier at siemens.com
Tue Apr 26 05:52:06 UTC 2011
On Mon, 25-Apr-2011 at 23:03:18 +0200, John Baldwin wrote:
> On Wednesday, April 20, 2011 1:32:26 am Andre Albsmeier wrote:
> > On Tue, 19-Apr-2011 at 15:20:25 +0200, John Baldwin wrote:
> > > On Tuesday, April 19, 2011 8:56:48 am Andre Albsmeier wrote:
> > > > On Mon, 18-Apr-2011 at 15:18:25 +0200, John Baldwin wrote:
> > > > > On Monday, April 18, 2011 7:36:57 am Andre Albsmeier wrote:
> > > > > > On Fri, 15-Apr-2011 at 18:35:05 +0200, John Baldwin wrote:
> > > > > > > On Friday, April 15, 2011 9:25:25 am Andre Albsmeier wrote:
> > > > > > > > On Fri, 04-Feb-2011 at 14:44:59 +0000, John Baldwin wrote:
> > > > > > > > > Author: jhb
> > > > > > > > > Date: Fri Feb 4 14:44:59 2011
> > > > > > > > > New Revision: 218277
> > > > > > > > > URL: http://svn.freebsd.org/changeset/base/218277
> > > > > > > > >
> > > > > > > > > Log:
> > > > > > > > > MFC 217075:
> > > > > > > > > Retire PCONFIG and leave the priority of thread0 alone when
> waiting for
> > > > > > > > > interrupt config hooks to execute.
> > > > > > > > >
> > > > > > > > > To preserve the KBI, I did not renumber priorities but
> simply removed
> > > > > > > > > PCONFIG.
> > > > > > > > >
> > > > > > > > > Modified:
> > > > > > > > > stable/7/sys/kern/subr_autoconf.c
> > > > > > > > > stable/7/sys/sys/priority.h
> > > > > > > > > Directory Properties:
> > > > > > > > > stable/7/sys/ (props changed)
> > > > > > > > > stable/7/sys/cddl/contrib/opensolaris/ (props changed)
> > > > > > > > > stable/7/sys/contrib/dev/acpica/ (props changed)
> > > > > > > > > stable/7/sys/contrib/pf/ (props changed)
> > > > > > > > >
> > > > > > > > > Modified: stable/7/sys/kern/subr_autoconf.c
> > > > > > > > >
> > > > > > >
> ==============================================================================
> > > > > > > > > --- stable/7/sys/kern/subr_autoconf.c Fri Feb 4 14:44:42
> 2011
> > > > > > > (r218276)
> > > > > > > > > +++ stable/7/sys/kern/subr_autoconf.c Fri Feb 4 14:44:59
> 2011
> > > > > > > (r218277)
> > > > > > > > > @@ -108,7 +108,7 @@ run_interrupt_driven_config_hooks(dummy)
> > > > > > > > > warned = 0;
> > > > > > > > > while (!TAILQ_EMPTY(&intr_config_hook_list)) {
> > > > > > > > > if (msleep(&intr_config_hook_list,
> &intr_config_hook_lock,
> > > > > > > > > - PCONFIG, "conifhk", WARNING_INTERVAL_SECS * hz) ==
> > > > > > > > > + 0, "conifhk", WARNING_INTERVAL_SECS * hz) ==
> > > > > > > > > EWOULDBLOCK) {
> > > > > > > > > mtx_unlock(&intr_config_hook_lock);
> > > > > > > > > warned++;
> > > > > > > >
> > > > > > > >
> > > > > > > > This broke several of my machines in a somewhat strange way:
> > > > > > > >
> > > > > > > > After upgrading them (17) to a recent 7-STABLE (as of
> 2011-04-12)
> > > > > > > > I noticed that some (4) of them didn't start. All 4 didn't find
> > > > > > > > their boot device anymore. What they all got in common is:
> > > > > > > >
> > > > > > > > - an Adaptec 2940 Ultra SCSI adapter
> > > > > > > > - two SCSI harddisks (da0 and da1) of various brands
> > > > > > > > - one SCSI CDROM drive (cd0)
> > > > > > > >
> > > > > > > > To be exact, none of the three devices (da0, da1, cd0) were
> > > > > > > > detected at all. Other machines with a similar configuration
> > > > > > > > (2940 and da0/da1) but _without_ the CDROM drive didn't have
> > > > > > > > any problems. So I simply removed the CDROM drives on the 4
> > > > > > > > machines in question and they all booted again.
> > > > > > > >
> > > > > > > > Today I decided to dig into this and after reverting(*) the
> > > > > > > > above change, they worked with the CDROM again. I have cross-
> > > > > > > > checked it 3 times. No idea what's happening here...
> > > > > > > >
> > > > > > > > -Andre
> > > > > > > >
> > > > > > > > (*) To be honest, I use this patch so I had to modify only one
> file:
> > > > > > > >
> > > > > > > > --- sys/kern/subr_autoconf.c.ORI 2011-02-05 13:14:11.000000000
> +0100
> > > > > > > > +++ sys/kern/subr_autoconf.c 2011-04-15 14:34:31.000000000
> +0200
> > > > > > > > @@ -108,7 +108,7 @@
> > > > > > > > warned = 0;
> > > > > > > > while (!TAILQ_EMPTY(&intr_config_hook_list)) {
> > > > > > > > if (msleep(&intr_config_hook_list, &intr_config_hook_lock,
> > > > > > > > - 0, "conifhk", WARNING_INTERVAL_SECS * hz) ==
> > > > > > > > + PRI_MIN_KERN + 32, "conifhk", WARNING_INTERVAL_SECS *
> hz) ==
> > > > > > > > EWOULDBLOCK) {
> > > > > > > > mtx_unlock(&intr_config_hook_lock);
> > > > > > > > warned++;
> > > > > > >
> > > > > > > Do you get any warnings about CAM timeouts, etc. when these probe?
> A verbose
> > > > > > > dmesg might be nice to look at if possible.
> > > > > >
> > > > > > OK, I have set up a machine for testing. In my other mail
> > > > > > I was wrong saying that the pass devices appear when using
> > > > > > the problematic kernel...
> > > > > >
> > > > > > Here are the dmesgs:
> > > > > >
> > > > > > - dmesg_bad is the original kernel as of Friday
> > > > > > - dmesg_ok is the patched kernel (see above) as of Friday
> > > > > > - dmesg.diff is the diff between both
> > > > > >
> > > > > > If you want me to try something just tell me...
> > > > >
> > > > > Hmmm, what if you make SCSI_DELAY larger? Also, can you let it fail
> the
> > > > > mount and drop into ddb and then get 'ps' output?
> > > >
> > > > As soon as I include the debugger into the kernel the problem
> > > > is gone. I have double-checked it two times now: With debugger
> > > > the drives are detected, without debugger mostly (but not always)
> > > > not.
> > > >
> > > > I currently have it running in an endless rebooting loop hoping,
> > > > that it fails eventually...
> > >
> > > Hummm. This seems like it is a timing related race. :(
> >
> > Success! Sometimes at night it finally panic'ed even with the
> > debugger in the kernel. Here is the output of 'ps' and some other
> > commands I remembered (no idea if any of these make sense in this
> > context :-)). It is still in this state with the serial console
> > attached so just tell me what to type ;-).
> >
> >
> > KDB: enter: manual escape to debugger
> > [thread pid 1 tid 100001 ]
> > Stopped at kdb_enter_why+0x3b: xorl %eax,%eax
> > db> ps
> > pid ppid pgrp uid state wmesg wchan cmd
> > 35 0 0 0 RL [softdepflush]
> > 34 0 0 0 RL [syncer]
> > 33 0 0 0 RL [vnlru]
> > 32 0 0 0 RL [bufdaemon]
> > 31 0 0 0 RL [pagezero]
> > 30 0 0 0 RL [idlepoll]
> > 29 0 0 0 RL [vmdaemon]
> > 28 0 0 0 RL [pagedaemon]
> > 27 0 0 0 WL [irq1: atkbd0]
> > 26 0 0 0 WL [swi0: uart uart]
> > 25 0 0 0 SL - 0xc182a63c [fdc0]
> > 24 0 0 0 SL idle 0xc1829600 [aic_recovery0]
> > 23 0 0 0 WL [irq11: ahc0]
> > 22 0 0 0 SL idle 0xc1829600 [aic_recovery0]
> > 21 0 0 0 WL [irq10: fxp0]
> > 20 0 0 0 WL [irq9: acpi0 intsmb0]
> > 19 0 0 0 SL - 0xc181b800 [kqueue taskq]
> > 18 0 0 0 WL [swi6: task queue]
> > 17 0 0 0 WL [swi6: Giant taskq]
> > --More-- 9 0 0 0 RL [thread
> taskq]
> > 16 0 0 0 WL [swi5: Fast task queue]
> > 15 0 0 0 WL [swi2: cambio]
> > 8 0 0 0 SL ccb_scan 0xc0766714 [xpt_thrd]
> > 7 0 0 0 SL - 0xc181bd80 [acpi_task_2]
> > 6 0 0 0 SL - 0xc181bd80 [acpi_task_1]
> > 5 0 0 0 SL - 0xc181bd80 [acpi_task_0]
> > 14 0 0 0 SL - 0xc077be54 [yarrow]
> > 4 0 0 0 SL - 0xc077942c [g_down]
> > 3 0 0 0 SL - 0xc0779428 [g_up]
> > 2 0 0 0 SL - 0xc0779420 [g_event]
> > 13 0 0 0 WL [swi3: vm]
> > 12 0 0 0 LL *Giant 0xc1821dc0 [swi4: clock]
> > 11 0 0 0 WL [swi1: net]
> > 10 0 0 0 RL [idle]
> > 1 0 0 0 RL CPU 0 [swapper]
> > 0 0 0 0 SLs sched 0xc07794c0 [swapper]
>
> Hummm, I don't see any "important" threads in a runnable state that I
> would think were denied the ability to run by the priority change. I wonder
> what callout swi4 is trying to run (or what other callouts might be
> stuck waiting for Giant). I'd be tempted to add some KTR traces or
> debugging printfs to try to figure out what sequence of events is
> happening when (e.g., when the xpt thread kicks off each scan CCB, when
> xpt_rescan_done() is called, and probably some events in the ahc driver).
I am happy to try whatever you suggest ;-) But I don't want to
steel too much of your time -- it seems that by reverting the
initial commit everythings runs fine for me and I can easily
live with that...
Thanks,
-Andre
>
> --
> John Baldwin
--
UNIX is an operating system, OS/2 is half an operating system,
Windows is a shell, and DOS is a bootsector virus.
More information about the freebsd-scsi
mailing list