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 = <none> 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 GaponReceived on Wed Sep 07 2016 - 08:42:01 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:07 UTC