Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756918AbcCRLOf (ORCPT ); Fri, 18 Mar 2016 07:14:35 -0400 Received: from mga14.intel.com ([192.55.52.115]:33141 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751658AbcCRLO0 (ORCPT ); Fri, 18 Mar 2016 07:14:26 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,354,1455004800"; d="scan'208";a="671827902" Message-ID: <56EBE485.1060301@linux.intel.com> Date: Fri, 18 Mar 2016 13:20:37 +0200 From: Mathias Nyman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Rajesh Bhagat , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org CC: gregkh@linuxfoundation.org, mathias.nyman@intel.com, sriram.dash@nxp.com Subject: Re: [PATCH] usb: xhci: Fix incomplete PM resume operation due to XHCI commmand timeout References: <1458284463-12743-1-git-send-email-rajesh.bhagat@nxp.com> In-Reply-To: <1458284463-12743-1-git-send-email-rajesh.bhagat@nxp.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1399 Lines: 36 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