From: Mathias Nyman <mathias.nyman@linux.intel.com>
To: Diego Viola <diego.viola@gmail.com>,
mathias.nyman@intel.com, Roger <rogerable@realtek.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>,
Greg KH <gregkh@linuxfoundation.org>,
Wei WANG <wei_wang@realsil.com.cn>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linux USB List <linux-usb@vger.kernel.org>,
Alan Stern <stern@rowland.harvard.edu>
Subject: Re: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3 is enabled
Date: Mon, 20 Mar 2017 16:21:32 +0200 [thread overview]
Message-ID: <58CFE56C.8050906@linux.intel.com> (raw)
In-Reply-To: <CA+ToGPGASfrDZyuv-p0V3yVFTQ33wi8kLE+DEQ=4Dt+VJvVG4w@mail.gmail.com>
On 19.03.2017 23:29, Diego Viola wrote:
> On Fri, Mar 17, 2017 at 5:18 PM, Diego Viola <diego.viola@gmail.com> wrote:
>> On Fri, Mar 17, 2017 at 1:57 PM, Diego Viola <diego.viola@gmail.com> wrote:
>>> On Fri, Mar 17, 2017 at 1:24 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
>>>> On Fri, 17 Mar 2017, Diego Viola wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Here's the log to the netconsole dmesg capture, I've used
>>>>> xhci_hcd.dyndbg no_console_suspend=1 as the kernel parameters.
>>>>>
>>>>> I did the usual suspend/resume cycle with i3lock, it hung after the
>>>>> third attempt when trying to resume from suspend.
>>>>>
>>>>> https://bugzilla.kernel.org/attachment.cgi?id=255309
>>>>
>>>> I'm not an expert on xHCI. This should be CC'ed to the xhci-hcd
>>>> maintainer.
>>>>
>>>> Alan Stern
>>>>
>>>>>
>>>>> Please let me know if I should provide something else.
>>>>>
>>>>> Thanks,
>>>>> Diego
>>>>>
>>>>
>>>
>>> I've forwarded my email to Mathias Nyman.
>>>
>>> Diego
>>
>> Still a problem with 4.11.0-rc2-ARCH+
>>
From a quick glance it looks like rtsx_usb_ms probaly takes a mutex (&ucr->dev_mutex)
and then issues a usb_bulk_msg() and waits for it to complete with mutex held.
The usb message times out, usb core kills the urb but the URB probably never gets completed,
and function never returns.
Everyting using ucr->dev_mutex would block, for example the kthread, rtsx_usb_detect_ms_card
that continuously tries to detect a ms card, takes and releases the same ucr->dev_mutex for
each try.
[ 614.026502] INFO: task kworker/u8:0:5 blocked for more than 120 seconds.
[ 614.027865] Not tainted 4.10.3-1-ARCH #1
[ 614.029116] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 614.030467] kworker/u8:0 D 0 5 2 0x00000000
[ 614.031812] Workqueue: kacpi_hotplug acpi_hotplug_work_fn
[ 614.033179] Call Trace:
[ 614.034550] __schedule+0x22f/0x700
[ 614.035940] schedule+0x3d/0x90
[ 614.037334] schedule_preempt_disabled+0x15/0x20
[ 614.038680] __mutex_lock_slowpath+0x19b/0x2d0
[ 614.040067] ? flush_workqueue+0x204/0x580
[ 614.041456] mutex_lock+0x23/0x30
[ 614.042163] acpi_device_hotplug+0x43/0x3e7
[ 614.042882] acpi_hotplug_work_fn+0x1e/0x29
[ 614.043612] process_one_work+0x1e5/0x470
[ 614.044356] worker_thread+0x48/0x4e0
[ 614.045077] kthread+0x101/0x140
[ 614.045788] ? process_one_work+0x470/0x470
[ 614.046495] ? kthread_create_on_node+0x60/0x60
[ 614.047215] ret_from_fork+0x2c/0x40
[ 614.047950] INFO: task rtsx_usb_ms_1:235 blocked for more than 120 seconds.
[ 614.048697] Not tainted 4.10.3-1-ARCH #1
[ 614.049465] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 614.050265] rtsx_usb_ms_1 D 0 235 2 0x00000000
[ 614.051064] Call Trace:
[ 614.051841] __schedule+0x22f/0x700
[ 614.052626] schedule+0x3d/0x90
[ 614.053411] usb_kill_urb.part.4+0x6c/0xa0 [usbcore]
[ 614.054198] ? wake_atomic_t_function+0x60/0x60
[ 614.055005] usb_kill_urb+0x21/0x30 [usbcore]
[ 614.055819] usb_start_wait_urb+0xe5/0x170 [usbcore]
[ 614.056652] usb_bulk_msg+0xbd/0x160 [usbcore]
[ 614.057489] rtsx_usb_send_cmd+0x63/0x90 [rtsx_usb]
[ 614.058306] rtsx_usb_read_register+0x6c/0xc0 [rtsx_usb]
[ 614.059118] rtsx_usb_detect_ms_card+0x98/0x120 [rtsx_usb_ms]
There is a lot going on in xhci during the last suspend befor this.
URBs are canceled, devices reset and re-enumerated, timeout while reading descriptor,
device firmware changed.
It's possible we end up in a situation where xhci never givers back the URB.
4.11-rc2 has better xhci tracing, it shows each URB enqueue and dequeue and giveback.
Could you try enabling xhci tracing before suspending (not the same as xhci verbose dynamic debug)
It will generate a lot of data, so better to remove all extra USB devices.
xhci tracing can be added with:
mount -t debugfs none /sys/kernel/debug
echo xhci-hcd >> /sys/kernel/debug/tracing/set_event
and then send the output of cat /sys/kernel/debug/tracing/trace
-Mathias
next prev parent reply other threads:[~2017-03-20 14:21 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-08 18:49 Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3 is enabled Diego Viola
2017-03-08 19:59 ` Diego Viola
2017-03-08 20:15 ` Greg KH
2017-03-08 20:40 ` Diego Viola
2017-03-09 14:11 ` Diego Viola
2017-03-09 17:15 ` Diego Viola
2017-03-14 17:20 ` Diego Viola
2017-03-14 19:15 ` Diego Viola
2017-03-15 14:00 ` Diego Viola
2017-03-16 14:03 ` Ulf Hansson
2017-03-16 15:07 ` Alan Stern
2017-03-16 15:45 ` Diego Viola
2017-03-16 15:51 ` Diego Viola
2017-03-16 16:02 ` Diego Viola
2017-03-16 16:19 ` Diego Viola
2017-03-16 17:14 ` Diego Viola
2017-03-16 18:47 ` Diego Viola
2017-03-17 15:55 ` Diego Viola
2017-03-17 16:24 ` Alan Stern
2017-03-17 16:57 ` Diego Viola
2017-03-17 20:18 ` Diego Viola
2017-03-19 21:29 ` Diego Viola
2017-03-20 14:21 ` Mathias Nyman [this message]
2017-03-20 15:39 ` Diego Viola
2017-03-20 16:32 ` Mathias Nyman
2017-03-20 18:27 ` Diego Viola
2017-03-20 23:15 ` Diego Viola
2017-03-21 13:04 ` Diego Viola
2017-03-21 15:29 ` Diego Viola
2017-03-21 22:52 ` Diego Viola
2017-03-22 17:51 ` Mathias Nyman
2017-03-23 17:02 ` Mathias Nyman
2017-03-23 17:12 ` Diego Viola
2017-03-24 13:12 ` [RFT PATCH] xhci: Manually give back cancelled URBs if queuing for cancel fails Mathias Nyman
2017-03-24 16:25 ` Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3 is enabled Diego Viola
2017-03-27 7:04 ` Mathias Nyman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=58CFE56C.8050906@linux.intel.com \
--to=mathias.nyman@linux.intel.com \
--cc=diego.viola@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@intel.com \
--cc=rogerable@realtek.com \
--cc=stern@rowland.harvard.edu \
--cc=ulf.hansson@linaro.org \
--cc=wei_wang@realsil.com.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).