On Wed, 23 Jun 2004, Ian E. Morgan wrote: > On Wed, 23 Jun 2004, Alan Stern wrote: > > > It's much more likely that the same failure occurs in 2.4, but the bus > > reset code there works better than in 2.6 so you recover without deadlock. > > I would have expected to see delays then as the bus was being reset, but > there isn't any.
Then it didn't happen. You would have seen a minute or two of delays as various timeouts expired and device resets failed before the bus reset occurred. It sure would be nice to know why the card reader has problems with the commands sent by 2.6 but not 2.4... > >> is there a way to get more debug output? > > > > No. And there isn't anything you could learn anyway. The command was > > sent to the reader and we are waiting for it to send its response. > > Everything is perfectly normal, it's just that the reader doesn't respond. > > If that was really all there was too it, then I would expect that > disconnecting the reader from the USB and removing power from the reader > should cause things to be 'reset' to cold power-up state. If only it were that simple! Yes, unplugging the reader will reset the reader. But it won't reset Linux, which is still hung somewhere in the bus reset code. > But after doing > that, the USB subsystem is still dead, and plugging the devices back in and > powering them up still does not allow the subsystem to recover. The > [scsi_eh_n] thread stays in "D" state indefinitely, and I must reboot to > clear it. Like I said, the khubd thread and the SCSI error handler are both hung because of problems in the bus reset routine. > When the subsystem is locked, and I unplug the reader, I start getting: > > Jun 23 12:00:36 light kernel: uhci_hcd 0000:00:1d.0: suspend_hc > Jun 23 12:00:36 light kernel: uhci_hcd 0000:00:1d.0: wakeup_hc > > over and over (about every 2-3 seconds) in the logs, until I reattach the > reader, then it stops, but the subsystem is still otherwise locked and no > other debugging messages appear. This is without a hub between the device > and host. Yes, that's a typical symptom indicating that khubd is hung. The USB controller driver, seeing that no devices are plugged in, suspends the controller. But since the hub driver isn't alive to clear the connect-change status, the controller driver wakes up again. Repeat as long as you like... If we knew why your reader was failing in the first place, this whole situation could be avoided. As it is, we'll just have to hope the fixing the bus reset routine will take care of the problem. Alan Stern ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
