Date: Fri, 15 Apr 2011 15:25:25 +0200 From: Andre Albsmeier <Andre.Albsmeier@siemens.com> To: John Baldwin <jhb@FreeBSD.org> Cc: svn-src-all@FreeBSD.org, svn-src-stable-7@FreeBSD.org, Andre.Albsmeier@siemens.com Subject: Re: svn commit: r218277 - in stable/7/sys: kern sys Message-ID: <20110415132525.GA88202@curry.mchp.siemens.de> In-Reply-To: <201102041444.p14EixJP087709@svn.freebsd.org> References: <201102041444.p14EixJP087709@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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++;
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110415132525.GA88202>