> -----Original Message----- > From: Sarah Sharp [mailto:sarah.a.sharp@xxxxxxxxxxxxxxx] > Sent: Thursday, April 14, 2011 4:37 AM > To: CAI Qian > Cc: John Youn; Paul Zimmerman; Alan Stern; linux-usb@xxxxxxxxxxxxxxx; > Don Zickus; Xu, Andiry > Subject: [PATCH] xhci: Tell USB core both roothubs lost power. > > Cai, will you try the following patch with Andiry's work-around patch, > but not with Alan's patch? > > This solves the 2nd hibernate failure for me. I think Alan's patch was > masking underlying issues when the USB 3.0 roothub was not marked as > having lost power. The USB core really thought the USB 3.0 hard drive > was still there, which is why can_submit was set. Alan, do you think > your patch is still needed? > > With this patch (and not Alan's patch), I can successfully hibernate > multiple times. Unfortunately, with the USB 3.0 hub I have, I see that > the USB 3.0 hard drive can't be enumerated after the resume. The set > address command fails with a transfer error. Turning on and off the > hard drive (it's externally powered) doesn't help. Plugging it into > different ports on the USB 3.0 hub doesn't help. Only unplugging the > USB 3.0 hub and replugging it in allows the USB 3.0 hard drive to be > enumerated. > > Adding Andiry's work around patch doesn't seem to help the set address > issue, so I'm chalking that up to USB 3.0 hub wierdness. I haven't > tested with his 5 larger patches yet. At least the system can > hibernate > now, even if the user needs to unplug/replug their USB 3.0 devices to > make them work. > > Andiry, is your workaround patch needed to allow the system to suspend? > I can't test suspend on my box. > Do you mean the clear port power patch? Yes, it's needed to allow the system to suspend. Thanks, Andiry > 8<------------------------------------------------------------------->8 > > On a resume, when the power is lost during hibernate, the USB core will > call hub_reset_resume for the xHCI USB 2.0 roothub, but not for the USB > 3.0 roothub: > > [ 164.748310] usb usb1: root hub lost power or was reset > [ 164.748353] usb usb2: root hub lost power or was reset > [ 164.748487] usb usb3: root hub lost power or was reset > [ 164.748488] xhci_hcd 0000:01:00.0: Stop HCD > ... > [ 164.870039] hub 4-0:1.0: hub_resume > ... > [ 164.870054] hub 3-0:1.0: hub_reset_resume > > This causes issues later, because the USB core assumes the USB 3.0 hub > attached to the USB 3.0 roothub is still active. It attempts to queue > a > control URB for the external hub, which fails because all the device > slot contexts were released when the USB 3.0 roothub lost power: > > [ 164.980044] hub 4-1:1.0: hub_resume > [ 164.980047] xhci_hcd 0000:01:00.0: Get port status returned 0x10101 > [ 164.980049] xHCI xhci_urb_enqueue called with unaddressed device > [ 164.980053] hub 3-0:1.0: port 1: status 0101 change 0001 > [ 164.980056] hub 4-1:1.0: hub_port_status failed (err = -22) > [ 164.980060] xhci_hcd 0000:01:00.0: `MEM_WRITE_DWORD(3'b000, > 32'hffffc90008948440, 32'h202e1, 4'hf); > [ 164.980062] xHCI xhci_urb_enqueue called with unaddressed device > [ 164.980066] xhci_hcd 0000:01:00.0: clear port connect change, actual > port 0 status = 0x2e1 > [ 164.980069] hub 4-1:1.0: hub_port_status failed (err = -22) > [ 164.980072] xhci_hcd 0000:01:00.0: get port status, actual port 1 > status = 0x2a0 > [ 164.980074] xHCI xhci_urb_enqueue called with unaddressed device > [ 164.980077] xhci_hcd 0000:01:00.0: Get port status returned 0x100 > [ 164.980079] hub 4-1:1.0: hub_port_status failed (err = -22) > [ 164.980082] xHCI xhci_urb_enqueue called with unaddressed device > [ 164.980085] hub 4-1:1.0: hub_port_status failed (err = -22) > [ 164.980088] hub 4-1:1.0: port 4: status 0000 change 0000 > [ 164.980091] xHCI xhci_urb_enqueue called with unaddressed device > [ 164.980094] hub 4-1:1.0: activate --> -22 > [ 164.980113] xHCI xhci_urb_enqueue called with unaddressed device > [ 164.980117] hub 4-1:1.0: hub_port_status failed (err = -22) > [ 164.980119] xHCI xhci_urb_enqueue called with unaddressed device > [ 164.980123] hub 4-1:1.0: can't resume port 4, status -22 > [ 164.980126] hub 4-1:1.0: port 4 status ffff.ffff after resume, -22 > [ 164.980129] usb 4-1.4: can't resume, status -22 > [ 164.980131] hub 4-1:1.0: logical disconnect on port 4 > > This causes issues when a USB 3.0 hard drive is attached to the > external > USB 3.0 hub when the system is hibernated: > > [ 6249.849653] sd 8:0:0:0: [sdb] Unhandled error code > [ 6249.849659] sd 8:0:0:0: [sdb] Result: hostbyte=DID_ERROR > driverbyte=DRIVER_OK > [ 6249.849663] sd 8:0:0:0: [sdb] CDB: Read(10): 28 00 00 00 2a 08 00 00 > 02 00 > [ 6249.849671] end_request: I/O error, dev sdb, sector 10760 > > Make sure to inform the USB core that *both* xHCI roothubs lost power. > > Signed-off-by: Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx> > --- > drivers/usb/host/xhci.c | 4 +++- > 1 files changed, 3 insertions(+), 1 deletions(-) > > diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c > index 196e018..23ecc32 100644 > --- a/drivers/usb/host/xhci.c > +++ b/drivers/usb/host/xhci.c > @@ -771,7 +771,9 @@ int xhci_resume(struct xhci_hcd *xhci, bool > hibernated) > > /* If restore operation fails, re-initialize the HC during resume > */ > if ((temp & STS_SRE) || hibernated) { > - usb_root_hub_lost_power(hcd->self.root_hub); > + /* Let the USB core know _both_ roothubs lost power. */ > + usb_root_hub_lost_power(xhci->main_hcd->self.root_hub); > + usb_root_hub_lost_power(xhci->shared_hcd->self.root_hub); > > xhci_dbg(xhci, "Stop HCD\n"); > xhci_halt(xhci); > -- > 1.7.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
