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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
