> Jennifer and the other reporters of the issue most certainly all used > modular kernels, i.e. got the drivers loaded by udev. > > module_init() doesn't matter, but > - .probe(), > - .resume() > do. So as you say, if the drivers were statically linked, then at least > .probe() would be performed serially, one PCI device after another, > right? But AFAIK .resume() would still be performed in parallel by a > pool of kernel threads in current kernels. OK, I see. When both drivers are loaded near the same time via udev, the firewire driver doesn't work correctly. I don't know of anything that serializes driver registration from dynamically loaded modules. I wouldn't bother with the resume issue until after the load-time issue is resolved because suspend/resume makes things harder to debug. You might be able to try loading/unloading the modules in a loop to reproduce the issue in a single boot. > From what I can tell, there is no driver bug but an unfortunate interaction > between parts of a combo controller which in theory should functionally be > totally unrelated. That's plausible. But I can't think of anything useful the PCI core can do here. If you can identify a hardware issue in the device, it's possible you could write a quirk to work around it. But after the driver has called pci_enable_device() (the last point at which quirks are applied), the PCI core is pretty much out of the picture. Maybe something could be added to one or both drivers to look for these devices and try deal with them? I'm afraid I don't have any good ideas here. -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
