Messages in this thread | | | Date | Wed, 10 Feb 2016 18:50:06 +0200 | From | Mathias Nyman <> | Subject | Re: [PATCH] usb: host: xhci: Replace bus lock with host controller lock |
| |
On 05.02.2016 17:14, Chris Bainbridge wrote: > Running task list at fail point:
...
> Some of the functions appear to be inlined, the exact call chain is: > > 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 >
hub_port_reset() will end up moving the corresponding xhci device slot to default state.
As hub_port_reset() is called several times in hub_port_init() It sounds reasonable that we could end up with two threads having their xhci device slots in default state at the same time, which according to xhci 4.5.3 specs still is a big no no.
So both threads fail at their next task after this. One fails to read the descriptor, and the other fails addressing the device.
Nice catch btw.
> So xhci_setup_device is entered while there is an outstanding URB on the > other bus. Unless anyone can think of a better way to fix this I'll make > the requested changes and resend my patch. >
For what it's wort I think that this suggested controller mutex sounds like a good idea. Should work for xhci at least.
-Mathias
| |