On Thu, 3 Sep 2015, Roland Weber wrote: > Hello Alan, > > > The kernel freezes before the > > new log statements, or any others in hub.c, are executed. > > Wrong filename there, it's usb.c of course. I'm not sure what you mean by that. Everything we have been discussing is in hub.c, not usb.c. > I've collected debug output from the boot sequence of the > bad kernel, with extra entry/exit statements, and of the > last good kernel, without the extra statements. Below are > excerpts which hopefully catch all relevant lines. Because > of its size, I've attached the full output to the bug report > that I initially opened against my distribution. The boot sequence isn't enough. I need to see what happens when the system freezes. Also, the log doesn't go all the way back to the initial boot. Probably the kernel's log buffer overflowed and wrapped around because of all the useless systemd output. Is there any way you can tell systemd not to write its output to the kernel log buffer? Or failing that, can you expand the log buffer's size (increase CONFIG_LOG_BUF_SHIFT)? > The "good" kernel apparently has delays of 4 seconds > related to the "Cannot enable" problem. That doesn't mean anything. It's just the interval between retries. > The "bad" kernel > has no such problem at all. Any idea how that difference > in behavior can be caused by changing the implementation > of the workqueue? In the "good" kernel, the 1-1 device is probed _before_ the devices on bus 2, whereas in the "bad" kernel it is probed _after_ them. That could make a difference; the buses are supposed to be independent but they might not be. However, this is not relevant to the main problem, which is the hangs. (You can test this hypothesis by booting the "good" kernel, and after everything settles down, doing this: echo 0000:00:1d.0 >/sys/bus/pci/drivers/ehci-pci/unbind echo 0000:00:1d.0 >/sys/bus/pci/drivers/ehci-pci/bind If the guess is correct, the probes following this bind should succeed.) > There are two exit traces without a matching entry trace: > [ 2.990519] hub 2-0:1.0: exit > [ 17.092630] hub 1-0:1.0: exit > I guess the x-0 device init starts at a different function. No, the entry traces undoubtedly occurred earlier in the log and got overwritten when the log buffer wrapped around. 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
