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     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.

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