Re: Resuming rt73usb wireless network dongle: ep0in 3strikes

Alan Stern <[email protected]>
Newsgroups gmane.linux.usb.devel
Message-ID <[email protected]>
On Mon, 3 Sep 2007, Mattias Nissler wrote:

> Hi everybody,
> 
> the rt2x00 project is currently working to stabilize the ralink wireless
> drivers for normal users.
> 
> One issue issue we are struggling with is the resume handler for the
> rt73 usb device. Here is what I see:
> 
> When suspending the device manually using
> 
> echo -ne "suspend" > /sys/bus/usb/devices/2-6/level
> echo -ne "auto" > /sys/bus/usb/devices/2-6/level
> 
> everything works fine. I have attached the resulting log snippet in the
> file syslog_suspend_device.txt
> 
> However, when I do
> 
> echo -ne "test" > /sys/power/disk
> echo -ne "disk" > /sys/power/state
> 
> the resume handler borks, with lots of
> 
> Sep  3 12:32:32 kea ehci_hcd 0000:00:1d.7: devpath 6 ep0in 3strikes
> 
> messages in the logs for each attempt to access the device. Full logs
> are attached as syslog_suspend_to_disk.txt

I counted about 500 occurrences!  That seems a little extreme.  If the 
transfer doesn't succeed after a couple of retries, it hardly seems 
likely that another 498 will help.  Don't you think that could be cut 
down a bit?

> So what's the problem here? Is this a know problem? Is the resume
> handler incorrect? Or maybe the device cannot resume properly and needs
> to be blacklisted? All comments and suggestions welcome.

The problem is that either your device or else the EHCI controller it 
is attached to dropped the USB connection during the suspend.  The 
same thing happened to the Alcor Micro mass storage device attached to 
the same controller, which suggests the problem lies in the controller.  
Or maybe it lies in the BIOS, which could reset the controller during 
the initial stages of resuming.

The fact that the device survived the first round of tests indicates 
your driver is basically OK.

You might try connecting the device to your other EHCI controller, the 
one on the add-on PCI card.  The BIOS is less likely to interfere with 
that one since it isn't built into the motherboard.

Alan Stern


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.