lkml.org 
[lkml]   [2016]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] usb: core: hub: hub_port_init lock controller instead of bus
On 08.02.2016 15:49, Chris Bainbridge wrote:
> The XHCI controller presents two USB buses to the system - one for USB 2
> and one for USB 3. When only one bus is locked there is a race condition
> with two threads in hub_port_init:
>
> [ 8.984500] Call Trace:
> [ 8.985698] [<ffffffff81b9bab7>] schedule+0x37/0x90
> [ 8.986918] [<ffffffff817da7cd>] usb_kill_urb+0x8d/0xd0
> [ 8.988130] [<ffffffff8111e5e0>] ? wake_up_atomic_t+0x30/0x30
> [ 8.989343] [<ffffffff817dafbe>] usb_start_wait_urb+0xbe/0x150
> [ 8.990561] [<ffffffff817db10c>] usb_control_msg+0xbc/0xf0
> [ 8.991766] [<ffffffff817d07de>] hub_port_init+0x51e/0xb70
> [ 8.992964] [<ffffffff817d4697>] hub_event+0x817/0x1570
> [ 8.994156] [<ffffffff810f3e6f>] process_one_work+0x1ff/0x620
> [ 8.995342] [<ffffffff810f3dcf>] ? process_one_work+0x15f/0x620
> [ 8.996528] [<ffffffff810f4684>] worker_thread+0x64/0x4b0
> [ 8.997707] [<ffffffff810f4620>] ? rescuer_thread+0x390/0x390
> [ 8.998883] [<ffffffff810fa7f5>] kthread+0x105/0x120
> [ 9.000056] [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200
> [ 9.001241] [<ffffffff81ba183f>] ret_from_fork+0x3f/0x70
> [ 9.002420] [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200
>
> [ 9.870837] Call Trace:
> [ 9.875664] [<ffffffff817fd36d>] xhci_setup_device+0x53d/0xa40
> [ 9.876871] [<ffffffff817fd87e>] xhci_address_device+0xe/0x10
> [ 9.878068] [<ffffffff817d047f>] hub_port_init+0x1bf/0xb70
> [ 9.879262] [<ffffffff811247ed>] ? trace_hardirqs_on+0xd/0x10
> [ 9.880465] [<ffffffff817d4697>] hub_event+0x817/0x1570
> [ 9.881668] [<ffffffff810f3e6f>] process_one_work+0x1ff/0x620
> [ 9.882869] [<ffffffff810f3dcf>] ? process_one_work+0x15f/0x620
> [ 9.884074] [<ffffffff810f4684>] worker_thread+0x64/0x4b0
> [ 9.885268] [<ffffffff810f4620>] ? rescuer_thread+0x390/0x390
> [ 9.886457] [<ffffffff810fa7f5>] kthread+0x105/0x120
> [ 9.887634] [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200
> [ 9.888817] [<ffffffff81ba183f>] ret_from_fork+0x3f/0x70
> [ 9.889995] [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200
>
> Which results from the two call chains:
>
> hub_port_init
> usb_get_device_descriptor
> usb_get_descriptor
> usb_control_msg
> usb_internal_control_msg
> usb_start_wait_urb
> usb_submit_urb / wait_for_completion_timeout / usb_kill_urb
>
> hub_port_init
> hub_set_address
> xhci_address_device
> xhci_setup_device
>
> The logged kernel errors are:
>
> [ 8.034843] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
> [ 13.183701] usb 3-3: device descriptor read/all, error -110
>
> On a test system this failure occurred on 6% of all boots.
>
> Hypothetically, it should perhaps be possible to set the address of the
> hub on one bus while the hub on the other bus already has an outstanding
> descriptor read request. But as this is not working reliably, fix it by
> locking the controller in hub_port_init to prevent parallel
> initialisation of both buses.
>

Most likely xhci is messed up after two device slots are in default state at the same time.
This happens when both threads are in hub_port_init() have called hub_port_reset()

The issue becomes visible when the the descriptor read and set address both fail after
the port resets.

xhci specs 4.5.3 has one tiny note about this:
"Note: Software shall not transition more than one Device Slot to the Default State at a time"

So to me, and from xhci pov this patch looks like the correct solution,
but I might be missing some usb core side details.

-Mathias

\
 
 \ /
  Last update: 2016-02-10 18:21    [W:0.128 / U:0.328 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site