On Sun, 23 Aug 2015, Roland Weber wrote: > Hello Alan, > > bisecting turned out to be much simpler than I was afraid of. > Here's the result: > > 638139eb95d2d241781330a321e88c8dafe46078 is the first bad commit > commit 638139eb95d2d241781330a321e88c8dafe46078 > Author: Petr Mladek <pmladek@xxxxxxx> > Date: Fri Sep 19 17:32:24 2014 +0200 > > usb: hub: allow to process more usb hub events in parallel > > It seems that only choose_devnum() was not ready to process more hub > events at the same time. > > All should be fine if we take bus->usb_address0_mutex there. It will > make sure that more devnums will not be chosen for the given bus and > the related devices at the same time. > > Signed-off-by: Petr Mladek <pmladek@xxxxxxx> > Acked-by: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> > Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> > > :040000 040000 6c3b464b8db2bec572cf7904c0aac317b41c1eec da3ee40957d0637f17895ae05aad4a6646377b2a M drivers Hmmm. I can't see how that commit would cause such a drastic hang. Are you certain you found the right one? That is, if you check out that commit and build a kernel it hangs, but if you check out the parent commit (37ebb54915dc), it doesn't hang? Furthermore, the code changed by that commit doesn't run when you do "lsusb -v". It runs only when the USB stack first starts up or when a new host controller is registered. I just tested lsusb -v for several root hubs on my computer, which is currently running a 4.1.4 kernel. It worked okay. Can you check more carefully? For example, see if reverting that commit makes a difference? Alan Stern -- 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
