From owner-freebsd-current@freebsd.org Wed Sep 7 10:42:01 2016 Return-Path: Delivered-To: freebsd-current@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 62D30BCFDC9; Wed, 7 Sep 2016 10:42:01 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4CC67698; Wed, 7 Sep 2016 10:41:59 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA29124; Wed, 07 Sep 2016 13:41:57 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1bhaIn-000MVm-Bc; Wed, 07 Sep 2016 13:41:57 +0300 To: freebsd-hackers , FreeBSD Current From: Andriy Gapon Subject: kldload intpm Message-ID: <9db20b27-254f-b0a5-8f6c-f1eeaadf7829@FreeBSD.org> Date: Wed, 7 Sep 2016 13:40:56 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2016 10:42:01 -0000 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. -- Andriy Gapon