Greg KH wrote: > On Wed, Feb 14, 2007 at 04:49:11PM -0600, [EMAIL PROTECTED] wrote: >> >> Hello... While running minor stress on a system, I'm seeing messages >> like this quite frequently: > > What kernel version are you using? >
2.6.20 > >> It seems to me that ehci-hcd itself should perhaps retry a >> transaction immediately--at least a couple of times--if it gets >> QTD_STS_MMF. If >> that is wrong for some reason, it might be nice if there was some way >> for hid-core (et al?) to know what's going on so it could opt to >> resubmit the URB right away--or at least not reset the device so >> hastily--if this is the cause of the URB failure... -EPROTO covers >> several other errors, too. > > Hm, care to make up a patch that would test this out? > Now that I've thought about it, I don't think that it makes sense for ehci-hcd to automatically reactivate the failed TD... because, when we get QTD_STS_MMF, it means that the transaction was already completed to the device on the low/full speed bus. If the broken split transaction was reading/writing data from a hard drive, and we just re-issue the read/write TD, I think we'll end up with data corruption... we'd need the usb-storage or scsi driver to realize that something went wrong and redo the whole CDB. But, even worse than that, other types of devices might lose data irretrievably. For example, if the broken split transaction had just read a keypress from a keyboard, and the TT threw away the keypress because we didn't complete the transaction in time, we couldn't get it back at all. (I've actually verified that my typing gets corrupted if I type for a few minutes during a kernel compile, though I'm sure most of the broken split transactions got a NAK from the keyboard.) So I think ideally linux needs some way of coordinating ehci-hcd and powernow, so that the EHCI controller can be stopped temporarily while the processors are changing speed... I'm going to try to hack something to do that, just to verify that it will fix the problem, but I'm not sure what the right way to implement that would be. (Or maybe it isn't worth implementing that, if everything non-HID could recover from this by re-doing stuff... I'm not familiar with all the USB device types.) The controller is getting quite a few QTD_STS_MMF errors, though--several per minute while compiling a kernel on my system with 4 HID devices behind USB 2.0 hubs. (I put in a printk so I could see every time qtd_copy_status() sees QTD_STS_MMF.) Stuart ------------------------------------------------------------------------- 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
