On Wed, 4 Oct 2006, Greg KH wrote:

> Ok, they still cause problems :)
> 
> I've applied them, and plugged a usb stick into a USB 2.0 hub and got
> the following:
> 
> [  375.562120] ehci_hcd 0000:00:1d.7: port 4 remote wakeup
> [  375.562134] hub 5-0:1.0: state 8 ports 8 chg 0000 evt 0000
> [  375.562141] usb usb5: usb auto-resume
> [  375.562147] usb usb5: finish resume
> [  375.562165] hub 5-0:1.0: hub_resume
> [  375.562172] ehci_hcd 0000:00:1d.7: resume root hub
> [  375.593289] hub 5-0:1.0: state 7 ports 8 chg 0000 evt 0000
> [  377.588840] hub 5-0:1.0: hub_suspend
> [  377.588898] usb usb5: usb auto-suspend
> 
> And the hub is now dead.  Unplug the device and plug it back in and
> nothing.
> 
> If I plug something into any other port on the hub, it too does not show
> anything.
> 
> Any hints on what I can do to debug this?

(I need to buy a high-speed hub so I can run these sorts of tests here...)

I don't know exactly where the trouble is, but here's what _should_ be 
happening:

In ehci-hcd.c:ehci_irq(), look at the block that starts with

        /* remote wakeup [4.3.1] */
        if (status & STS_PCD) {

Since you got the "port 4 remote wakeup" message in your log, this block 
is running and we know that (pstatus & PORT_RESUME) is non-zero and that 
ehci->reset_done[i] is set to 20 ms in the future.

Now look at ehci_hub.c:ehci_hub_status_data().  This routine should get 
called every 250 ms, starting from the "hub_resume" message in the 
log.  Buried inside the main loop is this ungainly test:

                if ((temp & (PORT_CSC | PORT_PEC | PORT_OCC)) != 0
                                // PORT_STAT_C_SUSPEND?
                                || ((temp & PORT_RESUME) != 0
                                        && time_after (jiffies,
                                                ehci->reset_done [i]))) {

As mentioned above, we know that (temp & PORT_RESUME) is non-zero.  The 
time_after() condition might not be true the very first time the 
subroutine gets called, but it certainly ought to be true the second time 
since 250 ms > 20 ms.  But apparently it isn't, since bit i+1 in buf 
remains 0 (that's the "evt 0000" value in the log).

So this is where you should concentrate your debugging.  The questions 
to be answered are:

        Is (temp & PORT_RESUME) really set?

        How does jiffies compare with ehci->reset_done[i]?

        Does the subroutine really get called every 250 ms?

Alan Stern


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

Reply via email to