On Tue, May 29, 2007 at 05:50:49PM -0400, Alan Stern wrote: > On Tue, 29 May 2007, Dan Aloni wrote: > > > Hello, > > > > We have a system where the rootfs is a partition on a USB device, > > and I've noticed upon a few rare cases where the USB controller > > loses the connection to the USB device after some uptime (days, > > weeks...), and the USB device reappears a very short time later. > > That failure mode is pretty uncommon. More often what happens is the > connection remains intact but communication/protocol/firmware/??? > errors cause the device to stop working. It never disappears but it > can't be used again without unplugging or power-cycling.
Yes this is also what I assume happening. i.e. more likely a USB flash disk firmware bug than a controller bug (there are lots of crappy USB flash drives out there). > > So, I gave some thoughts about this, I and came up with two > > main solutions: > > > > 1) Improve the USB storage error handling - bind the already > > existing SCSI host to the USB port that has the device, e.g., > > if host2 got created for usb 5-3 then keep it that way for the > > sake of EH. /dev/sda1 should come to life when the USB device > > recovers, unless a few seconds have passed or some attributes > > (such as manufactor id or serial) have changed. > > The difficulty here is that this "error" is indistinguishable from > normal activity -- someone simply unplugs the device and then later on > another connection is made. It might be the same device as before or > it might be a different one. In other words, it isn't really an error. > You would solve this by relying on "a few seconds" timeout. [...] > > It also goes against the USB specification. And it is potentially > unsafe, in that it is possible for users to change media or make other > alterations that the kernel cannot detect. The same would be true of > your proposal, assuming that somebody was quick enough to unplug one > device and plug in another (or swap memory cards) in the span of a few > seconds. The specific use case I refer to is with a flash drive embedded inside a locked and closed chassis of a dedicated server. So, anyone repluging it must know what they are doing anyway. -- Dan Aloni XIV LTD, http://www.xivstorage.com da-x (at) monatomic.org, dan (at) xiv.co.il - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/