lkml.org 
[lkml]   [2006]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Infinite retries reading the partition table
--- James Bottomley <James.Bottomley@SteelEye.com> wrote:
> On Tue, 2006-12-05 at 21:08 -0800, Andrew Morton wrote:
> > case MEDIUM_ERROR:
> > + if (sshdr.asc == 0x11 || /* UNRECOVERED READ ERR */
> > + sshdr.asc == 0x13 || /* AMNF DATA FIELD */
> > + sshdr.asc == 0x14) { /* RECORD NOT FOUND */
> > + return SUCCESS;
> > + }
> > return NEEDS_RETRY;
>
> If the complaint is true; i.e. infinite retries, this is just a bandaid
> not a fix. What it's doing is marking the unrecoverable medium errors
> for no retry. However, what we really need to know is why NEEDS_RETRY
> isn't terminating after its allotted number of retries. Can we please
> have a trace of this?

NEEDS_RETRY _does_ terminate, after it exhausts the retries. But since
by the ASC value we know that no amount of retries is going to work,
this chunk of the patch resolves it quicker, i.e. eliminates the
"NEEDS_RETRY" pointless retries (given the SK/ASC combination).

> > - if (scsi_end_request(cmd, 1, good_bytes, result == 0) == NULL)
> > + if (good_bytes &&
> > + scsi_end_request(cmd, 1, good_bytes, result == 0) == NULL)
> > return;
>
> What exactly is this supposed to be doing? its result is identical to
> the code it's replacing (because of the way scsi_end_request() processes
> its second argument), so it can't have any effect on the stated problem.

I suppose this is true, but I'd rather it not even go in
scsi_end_request as (cmd, uptodate=1, good_bytes=0, retry=0) and complete
at the bottom as (cmd, uptodate=0, total_xfer, retry=0).

Luben

-
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/

\
 
 \ /
  Last update: 2006-12-06 21:27    [W:0.040 / U:0.588 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site