On Wed, 6 Dec 2006, Dominik Brodowski wrote: > > > Now I tested this a bit further... and strangely, if I modprobe the USB > > > modules somewhen later, it is no problem at all. Running many many > > > possible > > > combinations of modprobe'ing yenta_socket, ehci_hcd, uhci_hcd and other > > > modules loaded at the same time in the init scripts I use, or even using > > > /etc/init.d/modules, does not reproduce the error... Very strange. > > > > I don't entirely trust git-bisect. Can you try reverting just this one > > patch by hand, to verify that the problem really does go away? > > Verified by hand, well, by "git reset HEAD^ && git checkout -f", and yes, > it's caused by autosuspend... BTW, why don't you entirely trust git-bisect?
Because in the past there have been occasions where people would say "git-bisect identified this as the offending patch" and it turned out they were wrong. > > Also, can you post a system log showing the problem with CONFIG_USB_DEBUG > > turned on? > > It's attached. > > > If you prevent ehci-hcd.ko from being loaded in the usual way (say by > > renaming it), does the problem still occur? > > No, it doesn't occur. > > > What about uhci-hcd.ko? > > If I rename ehci-hcd, uhci-hcd seems to be bound to that hub, and all works > well there. Also, ehci-hcd works fine > a) if my Matrox USB HD isn't connected to that port [haven't tested other > USB devices yet] or > b) if the modules uhci-hcd, ehci-hcd and yenta_socket[*] are modprobed in > any order after bootup. I can only reproduce it at the stage where udev > events are created through uevent at boot time -- it's right then when > udev is processing events that this error occurs. > > Any ideas? No doubt it's caused by the peculiar timing of events at startup. Lots of things are happening all at once, and the computer can't keep up with everything. For instance, your log shows the Matrox HD was detected at timestamp 23.0 roughly, but the usb-storage driver for it wasn't loaded until 30.97, by which time the HD had been autosuspended and the EHCI root hub along with it (at 25.2). Here's an experiment to try. Boot without the Maxtrox HD, and after everything has settled down, plug it in. Wait about 10 seconds for usb-storage to load and initialize. Then do "rmmod usb-storage" and wait another 10 seconds; the HD and EHCI should autosuspend. Perhaps at that point the "nobody cared" problem will occur again. Or perhaps not. I can't think of any reason why the EHCI controller should have generated the unhandled IRQ, and it seems very suspicious that it occurred just as the cs port probing was going on. So maybe yenta_socket is at fault, and the USB stuff just sets up the right timing conditions for the problem to show up. Alan Stern ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
