From owner-freebsd-hackers@freebsd.org Wed Sep 7 17:49:42 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8C319BD0E37; Wed, 7 Sep 2016 17:49:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6C56C6B5; Wed, 7 Sep 2016 17:49:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id 6D10210AF43; Wed, 7 Sep 2016 13:49:40 -0400 (EDT) From: John Baldwin To: Andriy Gapon Cc: freebsd-hackers , FreeBSD Current Subject: Re: kldload intpm Date: Wed, 07 Sep 2016 10:49:33 -0700 Message-ID: <16067820.jTuOsBSZ6N@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-PRERELEASE; KDE/4.14.10; amd64; ; ) In-Reply-To: <9db20b27-254f-b0a5-8f6c-f1eeaadf7829@FreeBSD.org> References: <9db20b27-254f-b0a5-8f6c-f1eeaadf7829@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Wed, 07 Sep 2016 13:49:40 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2016 17:49:42 -0000 On Wednesday, September 07, 2016 01:40:56 PM Andriy Gapon wrote: > > Has kldload intpm ever worked? > Ditto for other smbus drivers. > > The reason I am asking is that it doesn't work for me on the latest head. > And it doesn't work because device_probe_and_attach(sc->smbus) fails in > intsmb_attach(). > > With a little help from DTrace I obtained the following output: > CPU ID FUNCTION:NAME > 0 41924 devclass_add_driver:entry devclass = 0xfffff8000675b700, name > = pci, driver = 0xffffffff832ed058, name = intsmb > > 0 32121 device_probe_child:entry > parent = 0xfffff8000af78100, nameunit = intsmb0, devclass = 0xfffff8001d955880, > name = intsmb, driver = 0x0, name = > child = 0xfffff8001d933500, nameunit = smbus1, devclass = 0xfffff8001d955780, > name = smbus > > kernel`device_probe+0x9d > kernel`device_probe_and_attach+0x2e > intpm.ko`intsmb_attach+0x651 > kernel`device_attach+0x41d > kernel`pci_driver_added+0xed > kernel`devclass_driver_added+0x7d > kernel`devclass_add_driver+0x144 > kernel`module_register_init+0xb0 > kernel`linker_load_module+0xc88 > kernel`kern_kldload+0xa7 > kernel`sys_kldload+0x5b > kernel`amd64_syscall+0x2db > kernel`0xffffffff80e918ab > > 1 41924 devclass_add_driver:entry devclass = 0xfffff8001d955880, name > = intsmb, driver = 0xffffffff832ee930, name = smbus > > My interpretation is that intsmb_attach() is called before the smbus driver is > associated with the intsmb devclass. That means that the devclass does not have > any drivers at all when intsmb_attach() calls device_probe_and_attach() on its > smbus child. It's too late when the smbus driver is added to the intsmb devclass. > > Okay, writing the above gave me an idea to try to change the order of > DRIVER_MODULE() lines in intpm.c and that fixed the problem. > > But I seem to recall that some years ago kldload intpm worked without the > change. Perhaps the order has changed in the module loading code. > Anyway, this seems to be very subtle and error prone. I wonder if we could make > it more robust. You can request a specific ordering via DRIVER_MODULE_ORDERED (you can specify the SI_ORDER to use as an extra argument). The typical practice is to load the "base" driver (the one that attaches highest up the device hierarchy) "last" so that all other drivers are registered once it tries to attach. For example, in xl(4) this is used to to have the PCI attachment register last so that the miibus driver is registered when xl0 attaches: DRIVER_MODULE_ORDERED(xl, pci, xl_driver, xl_devclass, NULL, NULL, SI_ORDER_ANY); DRIVER_MODULE(miibus, xl, miibus_driver, miibus_devclass, NULL, NULL); DRIVER_MODULE() uses SI_ORDER_MIDDLE by default. This probably needs to be fixed in all of the smbus controller drivers. -- John Baldwin