On Mon, 29 Jan 2007, Dominik Brodowski wrote: > Allright, done some more debugging: > - using my patch with your fix, devices which are already plugged in when > the STS_FLR exception occurs continue to work > - however, new devices which are plugged in, or devices which are removed, > (unless the hub driver is awakened by other means) do not get noticed
This means that the port-change events don't generate interrupt requests. 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. > - the STS_FLR exception is easily reproducible for me: > - plug in USB HD > - rmmod usb_storage > - wait between one and seven seconds Yep, it seems to happen every time the root hub is suspended. Does it happen also if you simply unplug the USB HD? > > Are you entirely certain that 2.6.19 works perfectly? It does a lot less > > autosuspending than 2.6.20, true... But if you force a suspend in 2.6.19 > > do you then see the same sort of IRQ trouble? > > How do I force a suspend? Is suspend to RAM / suspend to disk enough to > force it, or from what you can else see in the dmesg? 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. 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