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
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
