On Mon, 8 Aug 2005, Luben Tuikov wrote: > On 08/08/05 16:41, Alan Stern wrote: > > I still have one related question. This is a little bit off to one > > side, but maybe you folks can suggest possible solutions. The question > > concerns a deadlock I _was_ able to generate earlier today with a patched > > usb-storage. > > > > My USB mass-storage test device doesn't respond to TEST UNIT READY, so it > > causes a timeout and kicks the error handler into action. This happens > > during device scanning, just prior to reading the partition table. The > > error handler goes through various stages of processing, leading up to a > > bus reset. I disconnected the USB device just before the bus reset > > routine was called. > > I think that "scanning" is a special process which should involve > the minimum of error handling, by either ignoring errors and trying > to connect to the device anyway, or on the first error, give up > the device. Which policy would one follow depends on the transport. No, that's not feasible. We can't just ignore errors, and we do have to cope with them. Scanning is a particular vulnerable time, since it involves sending commands that don't occur most of the time during normal operation. > If the latter, you need to blacklist the device as not supporting > TUR. Then on any error, like you pulling the cable during scanning, > the scanning process will give up and all will be well. You can't blacklist devices you don't know about. The kernel should work regardless. Alan Stern - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
