On Sun, 6 Sep 2015, Roland Weber wrote: > Hello Alan, > > thanks for bearing with me. > > > I'm not sure what you mean by that. Everything we have been discussing > > is in hub.c, not usb.c. > > Argh. That means I messed up the dynamic debug setting that was supposed > to enable the additional log statements. Luckily, I didn't need it anyway, > because we could see the entry/exit output even so. > > > The boot sequence isn't enough. I need to see what happens when the > > system freezes. > > And I'd like to give you that information, but there is no output > before the freeze. On the plus side, I think I can tell you why. No output at all? Even when you use a VT console and you do "echo 8 >proc/sys/kernel/printk"? > You've given me a new way to trigger the freeze on a "bad" kernel: > > > echo 0000:00:1d.0 >/sys/bus/pci/drivers/ehci-pci/unbind > > The output you are looking for would appear on the bind, correct? > But the system already freezes on the unbind. Is the workqueue that > was changed from ordered to unordered involved at that point, too? I don't think so, but the sequence of events is complex and maybe I have forgotten something. It would be nice to find out exactly where the unbind freezes. Here are some routines to check; try sprinkling printk or dev_info statements at various places within them: In hcd.c, usb_remove_hcd() and usb_deregister_bus(). In hub.c, usb_disconnect(), hub_disconnect(), hub_quiesce(), and release_devnum(). > > 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 > > [...] > > If the guess is correct, the probes following this bind should > > succeed.) > > Your guess is correct. If the order of the probes is relevant, although > it shouldn't be, maybe the order on shutdown/unbind also plays a role? Who knows? But bear in mind, probing inevitably involves communicating with the device, whereas unbind need not. On the other hand, the fact that probing order matters is itself a bug. > Coming from another angle: Is it possible to tell the kernel to ignore > the USB hub that causes my problems, so it won't get probed at all? > I'll need the machine in working order from October through December, > and I'd rather have it on a current kernel with special boot parameters > than on a backlevel kernel, or on one I have to patch myself. Try blacklisting the ehci-pci module. Unfortunately, there is no way to tell the kernel not to allow a driver to probe a particular device. > > grep -i -e 'usb\|hub' dmesg.nosystemd.txt # for the complete file, see > # https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1485057/+attachment/4458181/+files/dmesg.nosystemd.txt I don't see anything unusual in the log, at first glance. Tracking down the place where the freeze occurs will probably be more fruitful. 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
