On Fri, 4 Jun 2004, Greg KH wrote: > On Fri, Jun 04, 2004 at 03:39:11PM -0400, Zephaniah E. Hull wrote: > > Starting at 2.6.7-rc1 or so (that is when we first noticed it) the new > > pilot-link libusb back end started deadlocking the entire USB bus that > > the palm device was on. > > > > I have finally tracked it down to happening when we make the > > USBDEVFS_RESET ioctl, we never return from it and from that point on the > > bus in question is completely dead, no processing is done, no > > notifications of devices being plugged in or unplugged. > > > > This is still happening in 2.6.7-rc2-mm1. > > > > It seems to happen with both the UHCI and OHCI back ends, so it is > > probably above that. > > > > Given that there were heavy locking changes, I suspect that the case in > > question got screwed up somehow. > > This needs to go to the linux-usb-devel list, now CC: > > Anyway, can you look at the output of SysRq-T and see where the > processes are hung?
Although doing that may help a little, it probably isn't necessary. We've known for a long time that the device reset code is messed up, especially with regard to how it handles locking. At the moment I am engaged in writing a series of updates for the hub driver (which is where the device reset routine lives) to clean it up and generally straighten out all the locking problems. When that's done, getting usb_reset_device() to work correctly will be easy. It probably won't all be finished for another kernel release or two. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X. >From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
