On Saturday 04 December 2004 11:51 am, Alan Stern wrote: > > Last question first... I don't know exactly what is going on between ext3 > and SCSI. And remember that the block layer sits in the middle, to > confuse things even further. I suspect that the "device gone" information > doesn't get propagated all the way up, but I don't know where it gets > lost. Maybe you could raise this question with James Bottomley and Jens > Axboe.
Sounds about right -- it didn't emit any messages, which is why it's easy to forget about that layer. > Concerning the lack of resets... I don't fully understand the philosophy > used by the SCSI layer in its approach to error correction. Me either. I suspect part of it avoiding a "bus" reset in expectation that for "real SCSI" there will be multiple devices on the bus ... which for USB is typically not a valid assumption. > ... > In fact, I suggested skipping the class-specific reset entirely and > proceeding directly to the port reset, because that's what Windows does. Why does this not surprise me? :) > I suspect the best approach might end up being to reduce the > class-specific timeout and to automatically do a port reset whenever the > class-specific reset fails. In fact that's what I started to look at. In this case the class-specific request failed almost immediately with -EPROTO, so that would be a good indicator that if there's only one LUN, and one interface, usb_reset_device() might be worth trying. Thanks for the info ... you confirmed that I was at least on a reasonable track with that! - Dave ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
