Re: [Rt2400-devel] Resuming rt73usb wireless network dongle: ep0in 3strikes

On Wed, 2007-09-05 at 19:55 +0200, Mattias Nissler wrote:
> On Wed, 2007-09-05 at 09:02 +0200, Mattias Nissler wrote:
> > 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?
> 
> Ok, now I have ehci-hcd back in the kernel and see the problem again.
> Full suspend log is at
> http://www-user.rhrk.uni-kl.de/~nissler/rt73usb_sr/syslog_suspend_to_disk_4.txt
> 
> Note the port status word on resume is the same as in the previous log
> that didn't show the problem.

Hey, I got another suspicion: Have you noticed that the UHCI and EHCI
controller suspend/resume in different order in the two logs? That is
probably because after I had made ehci-hcd a module, it was loaded
after. In my syslog I have verified that ehci is loaded before uhci when
both are compiled in. Does that sound sensible? At least both drivers
talk to interrelated hardware...

I'll try to compile them both as modules and control the load order.

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