linux-kernel - Re: device plugged into xhci port not detected after a resume

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110615165842.GB5382@xanatos>
Date:	Wed, 15 Jun 2011 09:58:42 -0700
From:	Sarah Sharp <sarah.a.sharp@...ux.intel.com>
To:	Maarten Lankhorst <m.b.lankhorst@...il.com>
Cc:	linux-usb@...r.kernel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: device plugged into xhci port not detected after a resume

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.

Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/