Hi, On Mon, Jan 29, 2007 at 10:41:58AM -0500, Alan Stern wrote: > On Sun, 28 Jan 2007, Dominik Brodowski wrote: > > > > You could try another test: Let the IRQ be disabled, and then rmmod > > > ehci-hcd and modprobe it back. Perhaps then rmmod usb-storage to force > > > another suspend, perhaps not. Anyway, see what happens to intr_enable. > > > You can always force interrupts to occur by turning the USB HD off or on. > > > > Unfortunately, the IRQ line is and stays disabled, and I don't know how I > > could re-enable it. > > Loading a driver that uses the IRQ should re-enable it.
Ah, okay, need to remember that. Thanks. > > > It would be possible to patch the ehci_irq() routine to have it turn off > > > the STS_FLR bit whenever necessary. But first I would like to know what > > > causes it to turn on at all. Maybe it really is a hardware problem. > > > > I did that (see below), but then the IRQ subsystem continued to be "dead" > > -- it seemed to me that the USB hub is in a completely broken state when > > this codepath is entered... > > What exactly do you mean? 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 - the STS_FLR exception is easily reproducible for me: - plug in USB HD - rmmod usb_storage - wait between one and seven seconds > Can you provide a dmesg log with CONFIG_USB_DEBUG turned on? http://userweb.kernel.org/~brodo/dmesg-2.6.19.2 - 2.6.19.2 which really seems to work fine (even when doing suspend to RAM and suspend to disk) http://userweb.kernel.org/~brodo/dmesg-2.6.20-rc6 - the first part with all the intialization, and the first STS_FLR exception occuring http://userweb.kernel.org/~brodo/dmesg-2.6.20-rc6-part2 - second part where the USB devices are partly in use, partly suspending is forced, and STS_FLR exceptions occur > > To further complicate matters, I now also see IRQ10 being disabled whenever > > I switch from the console (i810) to a terminal -- but that bug was > > introduced _later_ than the autosuspend bug. And, 2.6.19 works perfectly > > fine with regard to both issues... > > 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? Hope this helps, Dominik ------------------------------------------------------------------------- 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
