On Mon, 11 Dec 2006, Dominik Brodowski wrote: > > Yes, that's right. In fact the controller isn't supposed to send an IRQ > > when only those two bits are on. I suspect the STS_FLR bit is somehow > > getting set in the intr_enable register (don't ask me how -- there doesn't > > seem to be any code that could do it). Can you modify the patch to print > > out the value of that register as well as the value of the status > > register? > > done (with only ehci-hcd being the only IRQ 10 user). > > case A) usb-storage device connected to "left" USB port: > > The flip occurs on or after IRQ status 8028 > > http://userweb.kernel.org/~brodo/dmesg-autosuspend-3.txt
There's no question; that's the reason for your problem. But I wonder how that bit ever managed to get turned on... I'll have to study the code some more. Which kernel did you say you are using? > case B) snd-usb-audio device connected to "right" USB port: > > The flip occurs on or after IRQ status 0004. > > http://userweb.kernel.org/~brodo/dmesg-autosuspend-2.txt > (unfortunately, without extended USB debug messages) And in this example there wasn't even a suspend-resume pair to confuse the issue, which suggests that the same thing might end up happening even without the patch git-bisect identified. Can you try running exactly the same test, but with that patch reverted? > Thanks, > Dominik > > > PS: the patch I used: It's fine. 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
