Re: EISA & sysfs.

[Dave Jones]

On Wed, Feb 18, 2004 at 10:42:49AM +0100, Marc Zyngier wrote:

 > Dave> Wouldn't it make sense to have eisa_driver_register() check that the
 > Dave> root EISA bus actually got registered, and if not, -ENODEV
 > Dave> immediately ?
 > 
 > Most of the time, the bus driver kicks in *after* the device driver is
 > registered to the EISA framework (eisa is second to last in the driver
 > list, so if the driver is built-in, it is guaranted to init before the
 > root driver has a chance to discover the bus).

sounds like the initcall needs a different priority.

 > So, returning -ENODEV immediatly in this case prevents you from using
 > any built-in EISA driver. A possible solution to this problem would be
 > to move eisa just after the pci init (and even that would cause some
 > trouble, because the virtual_root driver would register before the
 > parisc root driver has a chance to be probed...).
 > 
 > So yes, this sucks, but I can't come up with a better solution...

This problem is not just cosmetic btw, it kills boxes.
For example, hp100 is a net driver that supports multiple busses.
Trying to modprobe it on a kernel that supports EISA on a box that
doesn't gets a hung modprobe. Backtrace shows..

 modprobe      D 00000082     0 23407  15920                     (NOTLB)
        c1fe3f2c 00000082 c031ba08 00000082 ffffffff c031bb90 cc318219 00000092
        c6ee8ca0 c6ee8cc0 c111acc0 0040603e cc532c37 00000092 c267eca0 c267ee70
        c6c6375c 00000001 000005a0 c035ffcc ffffffff c7c5e644 c267eca0 c01d4583
 Call Trace:
  [<c01d4583>] rwsem_down_write_failed+0x141/0x15c
  [<c01d3742>] .text.lock.kobject+0x36/0x74
  [<c01d339a>] kobject_register+0x19/0x39
  [<c0221a5c>] bus_add_driver+0x2e/0x83
  [<c02622d4>] eisa_driver_register+0xf/0x19
  [<c786e91e>] hp100_module_init+0x12/0x2e [hp100]
  [<c013c0c0>] sys_init_module+0x14e/0x25e
  [<c010b697>] syscall_call+0x7/0xb

I've seen same exactly the same behaviour with quite a few other modules.
For my 'modprobe/rmmod script-o-death', I just ended up disabling EISA
in that test tree, as it was too painful to hit this issue over and over,
but its a real situation that could bite users of for eg, vendor kernels.

		Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/