From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756574AbZEZQIl (ORCPT ); Tue, 26 May 2009 12:08:41 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754393AbZEZQId (ORCPT ); Tue, 26 May 2009 12:08:33 -0400 Received: from mx2.redhat.com ([66.187.237.31]:56382 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753133AbZEZQIc (ORCPT ); Tue, 26 May 2009 12:08:32 -0400 Date: Tue, 26 May 2009 19:07:35 +0300 From: "Michael S. Tsirkin" To: Alan Stern Cc: Kay Sievers , OGAWA Hirofumi , Kernel development list , USB list Subject: Re: 2.a.30-rc7: fat filesystem misdetected as amiga Message-ID: <20090526160735.GB9842@redhat.com> References: <20090525212325.GD6856@redhat.com> <20090526160343.GA9842@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090526160343.GA9842@redhat.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 26, 2009 at 07:03:43PM +0300, Michael S. Tsirkin wrote: > On Tue, May 26, 2009 at 10:04:01AM -0400, Alan Stern wrote: > > On Tue, 26 May 2009, Michael S. Tsirkin wrote: > > > > > On Mon, May 25, 2009 at 05:08:12PM -0400, Alan Stern wrote: > > > > On Mon, 25 May 2009, Michael S. Tsirkin wrote: > > > > > > > > > > So apparently this is a bug in the device; it doesn't respond correctly > > > > > > to the first READ command. But since it does respond correctly to > > > > > > later commands, everything works okay thereafter. You ought to be able > > > > > > to recover from the error by running > > > > > > > > > > > > blockdev --rereadpt /dev/sdb > > > > > > > > > > > > manually. > > > > > > > > > > Yes, this helps. > > > > > Would it make sense for kernel to retry automatically? > > > > > Why doesn't it? > > > > > > > > I don't know the details in this case. Most likely the error code > > > > (Logical Block Address Out of Range) is interpreted as a fatal > > > > non-retryable error. For other sorts of errors, the kernel does retry. > > > > > > Who would know? The scsi crowd? > > > > They would know. But it's easy enough to find out. (Looks through > > the SCSI code...) Here we go. scsi_io_completion() contains this: > > > > case ILLEGAL_REQUEST: > > /* If we had an ILLEGAL REQUEST returned, then > > * we may have performed an unsupported > > * command. The only thing this should be > > * would be a ten byte read where only a six > > * byte read was supported. Also, on a system > > * where READ CAPACITY failed, we may have > > * read past the end of the disk. > > */ > > if ((cmd->device->use_10_for_rw && > > sshdr.asc == 0x20 && sshdr.ascq == 0x00) && > > (cmd->cmnd[0] == READ_10 || > > cmd->cmnd[0] == WRITE_10)) { > > /* This will issue a new 6-byte command. */ > > cmd->device->use_10_for_rw = 0; > > action = ACTION_REPREP; > > } else if (sshdr.asc == 0x10) /* DIX */ { > > description = "Host Data Integrity Failure"; > > action = ACTION_FAIL; > > error = -EILSEQ; > > } else > > action = ACTION_FAIL; > > break; > > Which kernel version is this? I see different code in 2.6.30-rc7. Sorry, looked at the wrong file. I see this in drivers/scsi/scsi_lib.c -- MST