From owner-svn-src-head@FreeBSD.ORG Wed Mar 25 16:59:33 2009 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34E36106567D; Wed, 25 Mar 2009 16:59:33 +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 05A598FC17; Wed, 25 Mar 2009 16:59:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 6DDB846B45; Wed, 25 Mar 2009 12:59:32 -0400 (EDT) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n2PGxQv4074311; Wed, 25 Mar 2009 12:59:26 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Warner Losh Date: Wed, 25 Mar 2009 12:59:20 -0400 User-Agent: KMail/1.9.7 References: <200903091320.n29DKNT8027311@svn.freebsd.org> In-Reply-To: <200903091320.n29DKNT8027311@svn.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903251259.20921.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 25 Mar 2009 12:59:26 -0400 (EDT) X-Virus-Scanned: ClamAV 0.94.2/9165/Wed Mar 25 11:08:41 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r189574 - head/sys/kern X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 16:59:34 -0000 On Monday 09 March 2009 9:20:23 am Warner Losh wrote: > Author: imp > Date: Mon Mar 9 13:20:23 2009 > New Revision: 189574 > URL: http://svn.freebsd.org/changeset/base/189574 > > Log: > Fix a long-standing bug in newbus. It was introduced when subclassing > was introduced. If you have a bus, say cardbus, that is derived from > a base-bus (say PCI), then ordinarily all PCI drivers would attach to > cardbus devices. However, there had been one exception: kldload > wouldn't work. > > The problem is in devclass_add_driver. In this routine, all we did > was call to the pci device's BUS_DRIVER_ADDED routine. However, since > cardbus bus instances had a different devclass, none of them were > called. > > Modified: head/sys/kern/subr_bus.c > ============================================================================== > --- head/sys/kern/subr_bus.c Mon Mar 9 13:12:48 2009 (r189573) > +++ head/sys/kern/subr_bus.c Mon Mar 9 13:20:23 2009 (r189574) > @@ -82,6 +82,8 @@ struct devclass { > char *name; > device_t *devices; /* array of devices indexed by unit */ > int maxunit; /* size of devices array */ > + int flags; > +#define DC_HAS_CHILDREN 1 > > struct sysctl_ctx_list sysctl_ctx; > struct sysctl_oid *sysctl_tree; > @@ -813,6 +815,7 @@ devclass_find_internal(const char *class > if (parentname && dc && !dc->parent && > strcmp(classname, parentname) != 0) { > dc->parent = devclass_find_internal(parentname, NULL, FALSE); > + dc->parent->flags |= DC_HAS_CHILDREN; > } > > return (dc); So this is the cause of the recent reports of panics on boot. The problem is that when drivers are registered during boot they are loaded in a "random" order (depends on the order the objects are linked actually). The point, though, is that a subclass might register first. In that case, trying to set dc->parent will fail because the parent driver isn't registered yet, so dc->parent will be NULL when it tries to set DC_HAS_CHILDREN. Just not setting the flag if dc->parent is NULL will fix the panics, but I think you can have baseclasses that won't have DC_HAS_CHILDREN set. Perhaps the second devclass there should always create a devclass (i.e. last param is true)? Otherwise dc->parent could be NULL when it shouldn't be, either. I think that is probably the best solution. I've tested this and it worked. -- John Baldwin