svn commit: r218277 - in stable/7/sys: kern sys

[John Baldwin]

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.

-- 
John Baldwin