Re: Resuming rt73usb wireless network dongle: ep0in 3strikes

On Tue, 2007-09-04 at 15:07 -0400, Alan Stern wrote:
> 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.

Done that, uploaded a new log to
http://www-user.rhrk.uni-kl.de/~nissler/rt73usb_sr/syslog_suspend_to_disk_3.txt

The funny thing about this log is that it is one of the (rare) ones
where the resume actually succeeds without any usb problems :-)

Hell, I just realize it seems to *work* now! I've just run 4 tests and
each time it came back as it should. I was never able to do this
before... Only thing I changed is ehci-hcd now being a module and the
ehci_dbg() call in the loop that prints the port status word. Weirdness!

Anyway, I don't have more time right know, will try to compile ehci-hcd
back into the kernel and see whether the issue comes back then... Maybe
it's a timing problem?

> 
> 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.

Yes. I have a report of one person having an ATI EHCI that doesn't
disconnect devices.

Mattias


-------------------------------------------------------------------------
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