On Tue, 30 Jan 2007, Dominik Brodowski wrote: > > Try running this test again, with CONFIG_USB_DEBUG turned on. After > > plugging in a new device, make a copy of > > > > /sys/class/usb_host/usb_host1/registers > > > > and post it. Ditto for unplugging an existing device. > > http://userweb.kernel.org/~brodo/pre-removal > => removed device 1 > http://userweb.kernel.org/~brodo/post-removal > => removed device 2 > http://userweb.kernel.org/~brodo/post-removal2 > > next test: > http://userweb.kernel.org/~brodo/pre-insert > => added device 2 > http://userweb.kernel.org/~brodo/post-insert
These were all done with the controller supposedly suspended, right? But they all show that it is actually running! (Which isn't too surprising when you think about it, because the FLR bit can't get set unless the controller is running.) > The one thing which strikes me as odd is that all these tests are ONLY > reproducible if there is an usb device plugged in during boot. If it wasn't > plugged in there during boot, I can do whatever I want, everything works > perfectly fine. This combined with everything else suggests very strongly a bug in the BIOS. Have you checked for any BIOS updates? > > Turn on CONFIG_PM_SYSFS_DEPRECATED in your kernel build of 2.6.19. After > > booting and plugging in the USB HD, rmmod usb-storage. Then do > > > > echo -n 2 >/sys/bus/usb/devices/usb1/power/state > > > > That will force the root hub to suspend. > > Using this trick, I can get IRQ 10 being disabled. > > So technically it's not a regression, but... ;) There may not be anything we can do about a rogue BIOS, other than to avoid suspending the controller at all. Just to make sure, try this: In ehci-hub.c, near the end of ehci_bus_suspend(), print out the value returned by ehci_halt(). If it is 0 then we will know that the controller does get suspended correctly and something (the BIOS?) starts it up for no good reason. The fact that suspend-to-RAM and -to-disk work okay might be explained by other things happening during the suspend procedure. Not only is the USB controller suspended, but its interrupt mask is cleared and its upstream PCI link gets suspended as well. That might be enough to prevent the BIOS from interfering. Alan Stern ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
