On Mon, 25 Jan 2010, Rafael J. Wysocki wrote: > > You may have to delay 6/8 as well, since the controllers are PCI > > devices. Writing the new code shouldn't take too long, though. > > No problem with that. > > Alternatively, if Greg agrees, I can add your patches modifying this into this > series. Greg? > > I wonder, though. Since the controllers are PCI devices, we put them into D0 > and restore their standard config spaces in the dpm_list order at the "early" > resume stage. Doesn't that help here? No. The problem is that the "late" resume routines in the host controller drivers reinitialize the hardware, and existing connections (i.e., from before the system sleep) may not be handled properly if the controllers are initialized in the wrong order. > > > I'll try that, but my mkinitrd automatically puts the USB drivers into > > > initramfs. I guess I'll need to do some research to really verify it. :-) > > > > Then when you install the test kernel, mkinitrd should build a > > corresponding initramfs image with the modified drivers, right? > > Otherwise there would be a version mismatch error when the init code > > tried to load the old drivers into the new kernel. > > Yes, but then they are loaded during restore before the image is read and > the hardware is initialized. Would it still fail in that case? It wouldn't matter. What the boot kernel does shouldn't affect what happens after the image starts running. BTW, I should mention that these problems don't always occur 100% of the time, even when the order constraints are violated. There may still be other races that can affect the result. But try it and see... Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
