Re: errors with split transactions & powernow

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
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel