On Thu, 24 Jan 2008, Guennadi Liakhovetski wrote: > On Mon, 21 Jan 2008, Alan Stern wrote: > > > On Mon, 21 Jan 2008, Guennadi Liakhovetski wrote: > > > > > 2. Before, if such a reset happened when the disk was mounted it > > > definitely meant SCSI errors, most probably, a disconnect. Now (2.6.22 > > > Debian kernel) these resets seem to be handled transparently - no SCSI or > > > fs errors, just a delay in data transfer and then it just continues. Is > > > it > > > indeed a (relatively) new feature? > > > > New since about 2.6.10. :-) > > Hm, last kernel I used on this hardware with this hd was about 2.6.16, and > with that one I got disconnects and SCSI / fs errors with aborted > transactions.
The outcome of a reset depends on exactly what went wrong to cause the reset. Some faults can be recovered and others can't. I don't recall there being any changes in this area since 2.6.16. > > > How normal is it? > > > > On a well-working system it isn't normal at all. Resets like that are > > a sign of something wrong. It could be at the electrical level (cable > > connections or power levels), firmware level, media level (read/write > > errors), or possibly elsewhere. > > I just checked the same disk with another system, running the same > software. The hardware is quite different though. No errors there with the > same load pattern, that reliably produced errors on the first PC. Looks > like a host's problem? Could be... a power-supply issue perhaps. Or maybe a cable-connection issue. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
