Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751979AbdC0HDA (ORCPT ); Mon, 27 Mar 2017 03:03:00 -0400 Received: from mga06.intel.com ([134.134.136.31]:61232 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751563AbdC0HCt (ORCPT ); Mon, 27 Mar 2017 03:02:49 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,229,1486454400"; d="scan'208";a="948498863" Subject: Re: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3 is enabled To: Diego Viola , Mathias Nyman References: <58CFE56C.8050906@linux.intel.com> <58D00409.7060205@linux.intel.com> <58D2B98D.90909@linux.intel.com> <58D3FF97.8000202@linux.intel.com> Cc: Roger , Ulf Hansson , Greg KH , Wei WANG , "linux-kernel@vger.kernel.org" , Linux USB List , Alan Stern From: Mathias Nyman Message-ID: <58D8B990.9060006@intel.com> Date: Mon, 27 Mar 2017 10:04:48 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; 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: 3599 Lines: 119 On 24.03.2017 18:25, Diego Viola wrote: > On Thu, Mar 23, 2017 at 2:12 PM, Diego Viola wrote: >> On Thu, Mar 23, 2017 at 2:02 PM, Mathias Nyman >> wrote: >>> On 22.03.2017 19:51, Mathias Nyman wrote: >>>> >>>> On 22.03.2017 00:52, Diego Viola wrote: >>>>> >>>>> On Tue, Mar 21, 2017 at 12:29 PM, Diego Viola >>>>> wrote: >>>>>> >>>>>> On Tue, Mar 21, 2017 at 10:04 AM, Diego Viola >>>>>> wrote: >>>>>>> >>>>>>> On Mon, Mar 20, 2017 at 8:15 PM, Diego Viola >>>>>>> wrote: >>>>>>>> >>>>>>>> On Mon, Mar 20, 2017 at 3:27 PM, Diego Viola >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> On Mon, Mar 20, 2017 at 1:32 PM, Mathias Nyman >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> On 20.03.2017 17:39, Diego Viola wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Mon, Mar 20, 2017 at 11:21 AM, Mathias Nyman >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 19.03.2017 23:29, Diego Viola wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Still a problem with 4.11.0-rc2-ARCH+ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> xhci tracing can be added with: >>>>>>>>>>>> >>>>>>>>>>>> mount -t debugfs none /sys/kernel/debug >>>>>>>>>>>> echo xhci-hcd >> /sys/kernel/debug/tracing/set_event >>>>> >>>>> >>>>> Here's the log I was able to obtain today, dmesg + ftrace at the time >>>>> of the crash: >>>>> >>>>> https://bugzilla.kernel.org/attachment.cgi?id=255419 >>>>> >>>>> USB keyboard and mouse was plugged when I reproduced this. >>>>> >>>>> Please let me know if you need more info. >>>>> >>>> >>>> Thanks, I'm looking at the logs and so far the most suspicious looking >>>> entry is: >>>> >>>> [ 257.060941] rtsx_usb-254 0.... 119946155us : xhci_urb_enqueue: >>>> ep1out-bulk: urb ffff880105a93300 pipe 3221259520 length 0/12 sgs 0/0 stream >>>> 0 flags 00010000 >>>> [ 257.063601] rtsx_usb-254 0.... 119946162us : xhci_urb_enqueue: >>>> ep0out-control: urb ffff880105a93300 pipe 2147484928 length 0/0 sgs 0/0 >>>> stream 0 flags 00100000 >>>> >>>> It enqueues the same URB, without ever giving it back or actually queuing >>>> any trbs for >>>> the urb, wel,l it might just fail to enqueue it in the first place. >>>> >>>> I need to search for a URB that has been dequeued but never given back in >>>> the trace >>> >>> >>> Ok, found a much more likely candidate: >>> >>> [ 258.004078] kworker/-544 0d..1 121599183us : xhci_urb_dequeue: >>> ep1out-bulk: urb ffff880105a930c0 pipe 3221259520... >>> >>> We try to kill this URB "ffff880105a930c0", twice, and its never given back. >>> Trace is missing "xhci_dbg_cancel_urb: Cancel URB..." entry in log after >>> xhci_urb_dequeue, so it never got added to the list for cancellation in xhci >>> driver. >>> >>> xhci_urb_dequeue() has one place where it just returns an error without >>> giving back the urb or queuing it for cancellation. >>> This is in my opinion a bug in xhci_urb_dequeue() >>> >>> rtsx_usb_ms is a good test for usb, it seems to be constantly queuing urbs >>> at all >>> inappropriate times. >>> >>> If I write a patch can you try it out? >> >> Yes. >> >>> >>> -Mathias >>> >>> >>> >> >> Thanks, >> Diego > > Hi Mathias, > > I tested your patch with Linux 4.11-rc3 and can confirm that it solves > the problem. > > I've tested suspend and resume with i3lock 150 times and it works. > > Thank you, I appreciate it a lot. > > Diego > Great, I'll send it forward, it can still make 4.11 final. Thanks for testing -Mathias