> A 10 second delay will cause the scsi error handler thread to fire. This
> should cause all sorts of things to happen, but often winds up resulting in
> a deadlock -- not just with usb-storage, but with lots of SCSI controllers,
> too. See the linux-scsi archives for some of the discussion.
So I'm suspecting a similar deadlock in the SCSI error handling is also
happening when the inquiry command returns an error. As a shortcut
to the discussions -- will those deadlocks get fixed soon? :)
I'm also curious why the deadlock detection code (with ac kernel, kdb)
hasn't fingered that as the problem. Either a bug in that detection, or
a case that for some reason it can't/doesn't handle, I guess ... but I've
seen it finger deadlocks before. (And since it didn't in this case, that's
what led me down the "this feels like hardware problems" path...)
> Out of curiosity, can you see command_abort() called in the dmesg if you
> send kern.=debug to /dev/console?
Yes. Before the deadlock/hang ... that's in the high speed case. That's
the only way that the read URB will get unlinked, right? This device is
not responding to the read as expected, as you know. But a whole-OS
deadlock seems to be an excessively severe response ... :)
- Dave
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
