On Tue, 24 Nov 2009, Boaz Harrosh wrote: > > I would have expected the READ to be retried, but in these two cases > > it wasn't. The usbmon log contained five instances of this error > > sequence; the other three were retried successfully. I don't know what > > the difference was. > > > > Perhaps the time it took to complete. > > I have a very old IDE disk connected to a USB box here, and some bad sectors take ages > to return. One thing I wanted to investigate is why the complete Linux system is frozen > for minutes when I "cp" one of these bad-sectors and then every thing is back to normal. > It's just an inserted external box. Swap system and everything is on an another healthy HD. > As if the USB controller actually locks the PCI bus, or the interrupts are off for a long > while. (Or is it the BKL?) > > Do you have time stamps on these? Yes. Each of the unsuccessful reads, whether retried or not, lasted less than one millisecond. So that's probably not the reason. On Tue, 24 Nov 2009, Jan Kara wrote: > My naive guess would be that those non-retried reads were actually > readahead. That's not retried if I remember correctly. Later, when we > really needed the data, we sent another read request... That would be my guess too. I don't know how to verify it, though. If you're interested in pursuing this farther, I can show you how to generate equivalent errors on demand using an emulated USB drive. At this point it's not clear how much more one could learn by doing this, however. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
