On 10.08.2015 09:47, Torsten Hilbrich wrote: > Hello, Hi
> > I got the following stack trace when booting a 3.19.4 kernel (with > grsecurity enabled, but this should not be related here), possible at > the moment when the xhci driver was initially processing the USB devices: > > kernel BUG at lib/list_debug.c:39 > Workqueue;: usb_hub_wq hub_event > > __list_add > queue_command > xhci_queue_slot_control > xhci_alloc_dev > usb_alloc_dev > hub_event > process_one_work > > The complete screenshot with all information can be found at > http://picpaste.com/pics/IMG_20150805_072836-LAhi91tT.1439187381.jpg > > The system is a Lenovo T450s docked within a Lenovo Ultra Dock docking > station. Attached are two external USB3 hubs (no devices attached > there). USB devices attached during boot were a keyboard and a mouse, > both attached to the docking unit. The error was not yet reproducible. > > The error seems to indicate that the xhci->cmd_list got modified while > the list_add operation was taking place. I already checked the xhci code > and apart from some shutdown handling didn't find any place, were the > list was modified without taking the xhci->lock. > > Any idea, what might be the concurrent user causing this problem? > This looks like one of the issues that could be caused by the usb address mutex change around 3.18. The address mutex was changed from global to per USB bus. As xhci handles both a USB2 and a USB3 bus, and uses the same command queue for both buses it caused simiar problems, but most of them were fixed in fixed in patch: commit a00918d0521df1c7a2ec9143142a3ea998c8526d usb: host: xhci: add mutex for non-thread-safe data I quickly checked 3.19.4, but couldn't find the patch in there. -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html