On Wednesday 14 February 2007 2:49 pm, [EMAIL PROTECTED] wrote: > 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.
This is plausible. I don't think anyone else has come up with a way to reproduce MMF faults. I've never trusted the existing code to clean up after them, either ... certainly when it was written (six years ago !?!) there was no obvious way to generate such faults. > 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? > > 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. Makes sense to me. Go Forth And Patch! :) - Dave ------------------------------------------------------------------------- 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 _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
