On Tue, 25 Aug 2015, Roland Weber wrote: > Hi Alan, > > > > 638139eb95d2d241781330a321e88c8dafe46078 is the first bad commit > > > > Are you certain you found the right one? > > Yes. I kept all the kernels during bisecting and double-checked today. > That was the second-to-last one, and it freezes. The last one was > > parent commit (37ebb54915dc) > and it works. I'm including the output of "git bisect log" below. > I also used the opportunity to collect more system information and > directly compare the last working and the first freezing version. > Note that the device numbering has changed since then. In the > information below, the devices that cause the freeze are on the > USB bus 001. > > > 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. > > OK, now things are getting interesting. Might the code also run during > shutdown? I mentioned in my bug report that the system freezes on shutdown.
Not exactly. You wrote: "[1.] One line summary of the problem: "lsusb -v" as root freezes the kernel on Acer ES1-111M", which seems to imply that the system freezes when you run lsusb. At least, that's how I interpreted it. 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? Anyway, the changed code does not run during shutdown. > I can confirm now that this is also caused by the above commit. > > Furthermore, there are significant differences during startup. > The last good version prints a bunch of messages like these: > (see further below for full dmesg output) > > [ 13.883381] usb usb1-port1: Cannot enable. Maybe the USB cable is bad? > [ 13.941952] ehci-pci 0000:00:1d.0: port 1 reset error -110 > [ 14.814627] ehci-pci 0000:00:1d.0: port 1 reset error -110 > [ 15.631041] ehci-pci 0000:00:1d.0: port 1 reset error -110 > [ 16.448006] ehci-pci 0000:00:1d.0: port 1 reset error -110 > [ 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 > > So that is the bus in question. I have verified that it is not connected > to the external USB ports of the machine. So far, I haven't missed any > of the internal devices that I know of either. So I presume that this > USB bus is simply unused. Maybe the manufacturer decided to just leave > it disconnected, instead of properly grounding the pins? I doubt it, in view of your later finding... > With the commit that causes the freeze, these messages no longer appear. > Instead, the kernel finds an additional device that the previous version > did not. It's an USB hub, connected to bus 001 (last line): > > /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 5000M > /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 480M > |__ Port 2: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M > |__ Port 1: Dev 4, If 0, Class=Wireless, Driver=, 12M > |__ Port 1: Dev 4, If 1, Class=Wireless, Driver=, 12M > |__ Port 4: Dev 3, If 0, Class=Video, Driver=uvcvideo, 480M > |__ Port 4: Dev 3, If 1, Class=Video, Driver=uvcvideo, 480M > /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/8p, 480M > |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M 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. 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. > Could it be that "lsusb -v" triggers a lazy initialization of that hub? Not "lazy", but it would cause the probe sequence to occur again. This time it might succeed -- you should be able to tell from the dmesg log. > And that the shutdown sequence does the same? No. Alan Stern -- 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
