Re: Resuming rt73usb wireless network dongle: ep0in 3strikes

On Tue, 4 Sep 2007, Mattias Nissler wrote:

> Ok, it's here:
> http://www-user.rhrk.uni-kl.de/~nissler/rt73usb_sr/syslog_suspend_to_disk_2.txt
> 
> Seems there are some more messages.
> 
> For example:
> 
> Sep  4 18:59:22 kea ehci_hcd 0000:00:1d.7: resume root hub
> 
> which is from ehci_pci_resume(). And it does *not* say "after power
> loss". I think this is correct ;-)
> 
> So what else happens there?

The actual sequence of events went like this:

Note that although the driver does get a suspend call, the device
itself does not specifically get suspended.  That's because this is a
FREEZE, and the stack knows that suspending the root hub is sufficient.
(When a root hub is suspended, all the devices on its bus automatically
suspend themselves.  ehci-hcd goes even farther than that -- when the 
root hub is suspended, the driver first suspends all the active ports.)

Likewise, the device does not specifically get resumed.  That's why
no problems show up until the driver's resume method is called.

There really and truly was a disconnect event.  This is demonstrated by
the lines saying:

Sep  4 18:59:22 kea ehci_hcd 0000:00:1d.7: GetStatus port 3 status 001803 POWER sig=j CSC CONNECT
Sep  4 18:59:22 kea ehci_hcd 0000:00:1d.7: GetStatus port 6 status 001803 POWER sig=j CSC CONNECT

The CSC means "Connect Status Change"; i.e., the devices were
disconnected and now they are connected again.  We can't tell for sure
when those events happened, except that they clearly occurred before 
your driver was resumed -- they are the reason for all those "3strikes" 
errors.

You can try to get more information by editing ehci_bus_resume() in
drivers/usb/host/ehci-hub.c.  In the first loop, immediately after the
ehci_readl() call, have it print out the value of i and the value of 
temp (in hex).  That way you'll be able to see the status of all the 
ports before anything else has happened.

It's not possible to know what caused the disconnections.  My best
guess is the BIOS or ACPI on the motherboard.  I think a good way to
approach this will be to try using a different brand of computer, maybe
even with a non-Intel motherboard, and compare results.

It's also worth noticing that the devices attached to the UHCI 
controller didn't get disconnected.  So you could try unloading 
ehci-hcd before the suspend, and see what happens then.

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