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? > usb 3-1.1: reset full speed USB device using ehci_hcd and address 5 > > These messages are occurring for all 4 of my low/full speed HID devices > that are connected to a USB2.0 hub (so all are using split transactions > on an interrupt pipe). This is occurring on an AMD system, and the > problem only occurs when the processors are changing speed > (powernow/cpufreq must be enabled). > > I added a few printks, and the failures are all because the EHCI > controller is setting QTD_STS_MMF (missed micro-frame), which means that > the EHCI controller started a split transaction but wasn't able to > complete it in time. > > I think this is happening because the EHCI controller is getting delayed > trying reading main memory while the processors are changing speed (this > is where the cpufreq/powernow stuff comes in). If this happens between > the start & complete parts of a split transaction, the EHCI controller > can't complete the split transaction in time, and it sets QTD_STS_MMF, > causing ehci-hcd to return -EPROTO to the hid-core driver. > > The function hid_io_error() in hid-core will in theory retry this > transaction every so often for up to a second, but, in reality, the > transaction isn't getting retried at all before the second is up, > because the system is loaded fairly heavily and the code that retries > the transaction is called by a timer and not run immediately in the > interrupt handler. > > Could anyone recommend a good way to fix this? Fix the TT code :) > 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? thanks, greg k-h ------------------------------------------------------------------------- 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
