linux-kernel - Re: [PATCH] usb: xhci: Fix incomplete PM resume operation due to XHCI commmand timeout

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: <56EBE485.1060301@linux.intel.com>
Date:	Fri, 18 Mar 2016 13:20:37 +0200
From:	Mathias Nyman <mathias.nyman@...ux.intel.com>
To:	Rajesh Bhagat <rajesh.bhagat@....com>, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
CC:	gregkh@...uxfoundation.org, mathias.nyman@...el.com,
	sriram.dash@....com
Subject: Re: [PATCH] usb: xhci: Fix incomplete PM resume operation due to
 XHCI commmand timeout

On 18.03.2016 09:01, Rajesh Bhagat wrote:
> We are facing issue while performing the system resume operation from STR
> where XHCI is going to indefinite hang/sleep state due to
> wait_for_completion API called in function xhci_alloc_dev for command
> TRB_ENABLE_SLOT which never completes.
>
> Now, xhci_handle_command_timeout function is called and prints
> "Command timeout" message but never calls complete API for above
> TRB_ENABLE_SLOT command as xhci_abort_cmd_ring is successful.
>
> Solution to above problem is:
> 1. calling xhci_cleanup_command_queue API even if xhci_abort_cmd_ring
>     is successful or not.
> 2. checking the status of reset_device in usb core code.


Hi

I think clearing the whole command ring is a bit too much in this case.
It may cause issues for all attached devices when one command times out.

We need to look in more detail why we fail to call completion for that one aborted command.

The bigger question is why the timeout happens in the first place?

What kernel version, and what xhci vendor was this triggered on?

It's possible that the timeout is related either to the locking issue found by Chris Bainbridge:
http://marc.info/?l=linux-usb&m=145493945408601&w=2

or the resume issues in this thread, (see full thread)
http://marc.info/?l=linux-usb&m=145477850706552&w=2

Does any of those proposed solutions fix the command timeout for you?

-Mathias