On Mon, Apr 27, 2015 at 02:17:45PM +0300, Mathias Nyman wrote: > On 27.04.2015 12:30, Johan Hovold wrote: > > On Sat, Apr 25, 2015 at 10:39:23PM +0100, Chris Bainbridge wrote: > >> Kernel: v4.0-10710-g27cf3a1 > >> > >> Hardware: > >> > >> IvyBridge Macbook (Panther Point PCH), 2 external USB3 ports > >> AmazonBasics 10 Port USB 3.0 Hub (3x VIA VL812 hub controllers) > >> > >> Bug: > >> > >> In ~7%-10% of boots there is an error: > >> > >> [ 0.604801] xhci_hcd 0000:00:14.0: Bad Slot ID 2 > >> [ 0.604802] xhci_hcd 0000:00:14.0: Could not allocate xHCI USB > >> device data structures > >> [ 0.604805] usb usb1-port3: couldn't allocate usb_device > >> > >> When this happens, no USB2 devices will be detected on the hub - the > >> three USB2 hub controllers (2109:2812) from the hub are not detected. > >> > >> This problem does not seem to occur in OS X: on 60 boots the USB2 > >> devices appeared every time. > > > > Does reverting > commit 6fecd4f2a58c60028b1a75deefcf111516d3f836 > USB: separate usb_address0 mutexes for each bus > Help? > > The "Bad Slot ID 2" followed by "Could not allocate xHCI USB device > data structures" is shown if we try to allocate device data structure > for an already existing device. > > We rely on a couple xhci wide variables during device enabling, > xhci->addr_dev and xhci->slot_id, and also rely on them being > protected by the usb_address0 mutex. As xhci handles both a USB-2 and > USB-3 bus and the mutex was changed to be per bus it's possible that > xhci->addr_dev and xhci_>slot_id race. That sounds like it could be related, although I've only seen this with 3.19 (fist and only boot) and that change went into 3.16. Chris, could you try reverting it as you seem to have a setup more suitable for testing this? Thanks, Johan -- 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
