Re: kldload intpm
On 07/09/2016 20:49, John Baldwin wrote: > 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. Thank you for the advice. I'm going to fix intpm. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: kldload intpm
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 IDFUNCTION:NAME > 0 41924devclass_add_driver:entry devclass = 0xf8000675b700, > name > = pci, driver = 0x832ed058, name = intsmb > > 0 32121 device_probe_child:entry > parent = 0xf8000af78100, nameunit = intsmb0, devclass = > 0xf8001d955880, > name = intsmb, driver = 0x0, name = > child = 0xf8001d933500, nameunit = smbus1, devclass = 0xf8001d955780, > 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`0x80e918ab > > 1 41924devclass_add_driver:entry devclass = 0xf8001d955880, > name > = intsmb, driver = 0x832ee930, 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 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
kldload intpm
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 IDFUNCTION:NAME 0 41924devclass_add_driver:entry devclass = 0xf8000675b700, name = pci, driver = 0x832ed058, name = intsmb 0 32121 device_probe_child:entry parent = 0xf8000af78100, nameunit = intsmb0, devclass = 0xf8001d955880, name = intsmb, driver = 0x0, name = child = 0xf8001d933500, nameunit = smbus1, devclass = 0xf8001d955780, 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`0x80e918ab 1 41924devclass_add_driver:entry devclass = 0xf8001d955880, name = intsmb, driver = 0x832ee930, 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 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
