kldload intpm
Andriy Gapon
avg at FreeBSD.org
Wed Sep 7 10:42:01 UTC 2016
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 Gapon
More information about the freebsd-hackers
mailing list