Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932649AbZKXT2g (ORCPT ); Tue, 24 Nov 2009 14:28:36 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1758164AbZKXT2f (ORCPT ); Tue, 24 Nov 2009 14:28:35 -0500 Received: from iolanthe.rowland.org ([192.131.102.54]:49237 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1757935AbZKXT2e (ORCPT ); Tue, 24 Nov 2009 14:28:34 -0500 Date: Tue, 24 Nov 2009 14:28:35 -0500 (EST) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Jan Kara , Boaz Harrosh cc: tmhikaru@gmail.com, Kernel development list , USB list , Jens Axboe , SCSI development list , Subject: Re: Weird I/O errors with USB hard drive not remounting filesystem readonly In-Reply-To: <4B0C1C20.2080901@panasas.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1787 Lines: 43 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-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/