From owner-svn-src-head@FreeBSD.ORG Wed Feb 11 07:57:27 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 2A00D1065678; Wed, 11 Feb 2009 07:57:27 +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 C19E38FC22; Wed, 11 Feb 2009 07:57:26 +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 n1B7tP8m062357; Wed, 11 Feb 2009 00:55:25 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 11 Feb 2009 00:55:24 -0700 (MST) Message-Id: <20090211.005524.-1889955595.imp@bsdimp.com> To: mav@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <200902110848450000@442211619> References: <200902110848450000@442211619> 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: r188464 - 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, 11 Feb 2009 07:57:28 -0000 In message: <200902110848450000@442211619> "Alexander Motin" writes: : > Alexander Motin writes: : > : Author: mav : > : Date: Tue Feb 10 23:22:29 2009 : > : New Revision: 188464 : > : URL: http://svn.freebsd.org/changeset/base/188464 : > : : > : Log: : > : Check for device_set_devclass() errors and skip driver probe/attach if any. : > : Attach call without devclass set crashes the system. : > : : > : On resume AHCI driver sometimes tries to create duplicate adX device. : > : It is surely his own problem, but IMHO it is not a reason to crash here. : > : Other reasons are also possible. : > : : > : Modified: : > : head/sys/kern/subr_bus.c : > : : > : Modified: head/sys/kern/subr_bus.c : > : ============================================================================== : > : --- head/sys/kern/subr_bus.c Tue Feb 10 23:17:20 2009 (r188463) : > : +++ head/sys/kern/subr_bus.c Tue Feb 10 23:22:29 2009 (r188464) : > : @@ -1756,8 +1756,13 @@ device_probe_child(device_t dev, device_ : > : dl = next_matching_driver(dc, child, dl)) { : > : PDEBUG(("Trying %s", DRIVERNAME(dl->driver))); : > : device_set_driver(child, dl->driver); : > : - if (!hasclass) : > : - device_set_devclass(child, dl->driver->name); : > : + if (!hasclass) { : > : + if (device_set_devclass(child, dl->driver->name)) { : > : + PDEBUG(("Unable to set device class")); : > : + device_set_driver(child, NULL); : > : + continue; : > : + } : > : + } : > : : > : /* Fetch any flags for the device before probing. */ : > : resource_int_value(dl->driver->name, child->unit, : > : > I'd prefer applying this patch to make it whine louder so we don't : > forget about it: : : device_set_devclass() itself already complains about driver problem (but only with verbose messages). At this point the only thing we should do is not to crash. As I have said, there also can be other failure reasons except driver bugs, for example, low memory. Low memory in this path is extremely rare, but we should report the reason... The most likely cause is a driver bug, and one we should complain about... Warner