From owner-svn-src-head@FreeBSD.ORG Wed Mar 25 17:04:58 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 2E810106576F; Wed, 25 Mar 2009 17:04:57 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 54D5D8FC25; Wed, 25 Mar 2009 17:04:56 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n2PH3tEg021100; Wed, 25 Mar 2009 11:03:55 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 25 Mar 2009 11:04:31 -0600 (MDT) Message-Id: <20090325.110431.-165354456.imp@bsdimp.com> To: jhb@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <200903251259.20921.jhb@freebsd.org> References: <200903091320.n29DKNT8027311@svn.freebsd.org> <200903251259.20921.jhb@freebsd.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 17:05:02 -0000 In message: <200903251259.20921.jhb@freebsd.org> John Baldwin writes: : 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. I think that's a good fix. And one that's needed if we want subclassing to work in the face of these random orderings. Otherwise, dc->parent wouldn't get set right anyway, and the function inheritance wouldn't happen correctly since it is NULL. Warner