From owner-svn-src-stable-7@FreeBSD.ORG Fri Apr 15 16:42:43 2011 Return-Path: Delivered-To: svn-src-stable-7@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 955471065678; Fri, 15 Apr 2011 16:42:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 549B78FC15; Fri, 15 Apr 2011 16:42:43 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id E5AEA46BA2; Fri, 15 Apr 2011 12:42:42 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 804038A01B; Fri, 15 Apr 2011 12:42:42 -0400 (EDT) From: John Baldwin To: Andre Albsmeier Date: Fri, 15 Apr 2011 12:35:05 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <201102041444.p14EixJP087709@svn.freebsd.org> <20110415132525.GA88202@curry.mchp.siemens.de> In-Reply-To: <20110415132525.GA88202@curry.mchp.siemens.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201104151235.05114.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 15 Apr 2011 12:42:42 -0400 (EDT) Cc: svn-src-all@freebsd.org, svn-src-stable-7@freebsd.org Subject: Re: svn commit: r218277 - in stable/7/sys: kern sys X-BeenThere: svn-src-stable-7@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for only the 7-stable src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 16:42:43 -0000 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