Op 15-06-11 18:58, Sarah Sharp schreef:
> On Wed, Jun 15, 2011 at 09:07:11AM +0200, Maarten Lankhorst wrote:
>> I plugged a simple usb mouse in xhci that isn't found after a resume.
>>
>> It's with the same lovely controller as I used with the previous bug.
>> Plugging in the controller to the same port doesn't cause it to be
>> detected again, I need to remodprobe xhci-hcd
> I will have to look at the log closely to be sure that this isn't a
> software issue, but it seems like the host controller just died after
> being suspended.
>
>
>> [ 505.821216] xhci_hcd 0000:04:00.0: Queueing ctrl tx for slot id 1, ep 0
> ...
>> [ 510.805001] xhci_hcd 0000:04:00.0: Cancel URB ffff8801c7a0ae40
> The xHCI driver submits a control transfer (probably to read the
> descriptor from your mouse) and the host doesn't give it back. It times
> out, so the xHCI driver issues a Stop Endpoint command to allow the
> driver to take the control transfer off the endpoint ring.
>
>> [ 515.794819] xhci_hcd 0000:04:00.0: xHCI host not responding to stop endpoint command.
> But the host doesn't respond to that command, so the xHCI driver assumes
> the hardware is hosed:
>
>> [ 515.794823] xhci_hcd 0000:04:00.0: Assuming host is dying, halting host.
>> [ 515.794830] xhci_hcd 0000:04:00.0: // Halt the HC
>> [ 515.794840] xhci_hcd 0000:04:00.0: Killing URBs for slot ID 1, ep index 0
>> [ 515.794847] xhci_hcd 0000:04:00.0: Killing URBs for slot ID 1, ep index 2
>> [ 515.794850] xhci_hcd 0000:04:00.0: Killing URBs for slot ID 1, ep index 4
>> [ 515.794854] xhci_hcd 0000:04:00.0: Calling usb_hc_died()
>> [ 515.794856] xhci_hcd 0000:04:00.0: HC died; cleaning up
>> [ 515.794860] xhci_hcd 0000:04:00.0: xHCI host controller is dead.
> Does the host controller work when you don't have any devices plugged
> in during resume? I.e. unplug the mouse and then re-plug it in on
> resume. Does suspend work when other devices are left plugged in?
>
> Does hibernate work, either with no devices plugged in, or the mouse
> plugged in? If it does work, the host controller may not be able to
> handle the context save and restore during suspend/resume, and we may
> need to unconditionally tell the USB core that the host lost power
> across suspend.
Yeah, manually overriding the resume function works. Tested with
- if ((temp & STS_SRE) || hibernated) {
+ if ((temp & STS_SRE) || hibernated || 1) {
~Maarten
--
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
