Hello Alan, > At the end, you also wrote "During shutdown of the OS, the kernel also > freezes." That's not entirely clear -- how can the kernel freeze > when you run "lsusb -v" and then freeze again during shutdown? > > Do you mean that the bad kernel freezes during shutdown even if you > don't run lsusb? Yes, that's exactly what I mean. Sorry for not writing that clearer. Whenever I boot a "bad" kernel, I know for sure it will freeze. I can work normally with the system, then it will freeze on shutdown. Or I can trigger the freeze earlier by calling "lsusb -v" as root. > Anyway, the changed code does not run during shutdown. Alright, here's another idea. The last good kernel finds an USB hub, gets a bunch of port reset errors and ignores that device. The first bad kernel also finds that USB hub, but doesn't report reset errors and doesn't ignore the device. > > [ 17.264644] ehci-pci 0000:00:1d.0: port 1 reset error -110 > > [ 17.874644] usb usb1-port1: Cannot enable. Maybe the USB cable is bad? > > [ 17.874677] usb usb1-port1: unable to enumerate USB device What if the bad kernel leaves data structures about that hub in an inconsistent state? And the freeze occurs not when the changed code executes, but some time later, when the data structures are accessed? There are no devices on that hub, so the data structures wouldn't be accessed when I just work with the system. But on shutdown, some de-initialization takes place, right? And "lsusb -v" triggers a probe sequence that would update the data structures. > This is very bizarre. The code changes are minimal; they should not > affect anything like detection of devices. The "Cannot enable" error > comes directly from the hardware. Or else the hardware behaves differently because the "bad" commit affects the timing of some initialization steps. > If you want, you could try an even finer bisection. The commit you > identified adds a mutex_lock and a mutex_unlock, and it also changes an > alloc_ordered_workqueue to alloc_workqueue. You could leave the mutex > stuff out and just include the alloc_workqueue change, or vice versa. Another kernel is being compiled as I write this. I undid the alloc_workqueue change, because I only had to change one line for that. I'll report the result later. thanks and cheers, Roland -- 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
