kldload intpm

From: Andriy Gapon <avg_at_FreeBSD.org>
Date: Wed, 7 Sep 2016 13:40:56 +0300
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
Received 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