public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Adrian Hunter <ext-adrian.hunter@nokia.com>
To: Pierre Ossman <drzeus@drzeus.cx>
Cc: LKML <linux-kernel@vger.kernel.org>,
	"Lavinen Jarkko (Nokia-M/Helsinki)" <jarkko.lavinen@nokia.com>,
	"Bityutskiy Artem (Nokia-M/Helsinki)"
	<Artem.Bityutskiy@nokia.com>
Subject: Re: [PATCH 2/2] mmc_block: ensure all sectors that do not have errors are read
Date: Mon, 10 Nov 2008 10:21:23 +0200	[thread overview]
Message-ID: <4917EF03.8060308@nokia.com> (raw)
In-Reply-To: <4908727F.5080003@nokia.com>

Adrian Hunter wrote:
> Pierre Ossman wrote:
>> On Thu, 16 Oct 2008 16:26:57 +0300
>> Adrian Hunter <ext-adrian.hunter@nokia.com> wrote:
>>
>>> If a card encounters an ECC error while reading a sector it will
>>> timeout.  Instead of reporting the entire I/O request as having
>>> an error, redo the I/O one sector at a time so that all readable
>>> sectors are provided to the upper layers.
>>>
>>> Signed-off-by: Adrian Hunter <ext-adrian.hunter@nokia.com>
>>> ---
>>
>> We actually had something like this on the table some time ago. It got
>> scrapped because of data integrity problems. This is just for reads
>> though, so I guess it should be safe.
>>
>>> @@ -278,6 +279,9 @@ static int mmc_blk_issue_rq(struct mmc_queue *mq, 
>>> struct request *req)
>>>          brq.stop.flags = MMC_RSP_SPI_R1B | MMC_RSP_R1B | MMC_CMD_AC;
>>>          brq.data.blocks = req->nr_sectors;
>>>  
>>> +        if (disable_multi && brq.data.blocks > 1)
>>> +            brq.data.blocks = 1;
>>> +
>>
>> A comment here would be nice.
> 
> Ok
> 
>> You also need to adjust the sg list when you change the block count.
>> There was code there that did that previously, but it got removed in
>> 2.6.27-rc1.
> 
> That is not necessary.  It is an optimisation.  In general, optimising an
> error path serves no purpose.
> 
>>> @@ -312,6 +318,13 @@ static int mmc_blk_issue_rq(struct mmc_queue 
>>> *mq, struct request *req)
>>>  
>>>          mmc_queue_bounce_post(mq);
>>>  
>>> +        if (multi && rq_data_dir(req) == READ &&
>>> +            brq.data.error == -ETIMEDOUT) {
>>> +            /* Redo read one sector at a time */
>>> +            disable_multi = 1;
>>> +            continue;
>>> +        }
>>> +
>>
>> Some concerns here:
>>
>> 1. "brq.data.blocks > 1" doesn't need to be optimised into its own
>> variable. It just obscures things.
> 
> But you have to assume that no driver changes the 'blocks' variable e.g.
> counts it down.  It is not an optimisation, it is just to improve
> reliability and readability.  What does it obscure?
> 
>> 2. A comment here as well. Explain what this does and why it is safe
>> (so people don't try to extend it to writes)
> 
> ok
> 
>> 3. You should check all errors, not just data.error and ETIMEDOUT.
> 
> No.  Data timeout is a special case.  The other errors are system errors.
> If there is a command error or stop error (which is also a command error)
> it means either there is a bug in the kernel or the controller or card
> has failed to follow the specification.  Under those circumstances
> 
> Data timeout on the other hand just means the data could not be retrieved
> - in the case we have seen because of ECC error.
> 
>> 4. You should first report the successfully transferred blocks as ok.
> 
> That is another optimisation of the error path i.e. not necessary.  It
> is simpler to just start processing the request again - which the patch
> does.
> 
>>> @@ -360,14 +373,21 @@ static int mmc_blk_issue_rq(struct mmc_queue 
>>> *mq, struct request *req)
>>>  #endif
>>>          }
>>>  
>>> -        if (brq.cmd.error || brq.data.error || brq.stop.error)
>>> +        if (brq.cmd.error || brq.stop.error)
>>>              goto cmd_err;
>>
>> Move your code to inside this if clause and you'll solve 3. and 4. in a
>> neat manner.
> 
> Well, I do not agree with 3 and 4.
> 
>> You might also want to print something so that it is
>> visible that the driver retried the transfer.
> 
> There are already two error messages per sector (one from this function
> and one from '__blk_end_request()', so another message is too much.
> 
>>>  
>>> -        /*
>>> -         * A block was successfully transferred.
>>> -         */
>>> +        if (brq.data.error) {
>>> +            if (brq.data.error == -ETIMEDOUT &&
>>> +                rq_data_dir(req) == READ) {
>>> +                err = -EIO;
>>> +                brq.data.bytes_xfered = brq.data.blksz;
>>> +            } else
>>> +                goto cmd_err;
>>> +        } else
>>> +            err = 0;
>>> +
>>>          spin_lock_irq(&md->lock);
>>> -        ret = __blk_end_request(req, 0, brq.data.bytes_xfered);
>>> +        ret = __blk_end_request(req, err, brq.data.bytes_xfered);
>>>          spin_unlock_irq(&md->lock);
>>>      } while (ret);
>>>  
>>
>> Instead of this big song and dance routine, just have a dedicated piece
>> of code for calling __blk_end_request() for the single sector failure.
> 
> Ok
> 
> Amended patch follows:

What is the status of this patch?


  reply	other threads:[~2008-11-10  8:13 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-16 13:26 [PATCH 2/2] mmc_block: ensure all sectors that do not have errors are read Adrian Hunter
2008-10-26 11:32 ` Pierre Ossman
2008-10-29 14:26   ` Adrian Hunter
2008-11-10  8:21     ` Adrian Hunter [this message]
2008-11-30 19:05     ` Pierre Ossman
2008-12-05 11:09       ` Adrian Hunter
2008-12-21 14:29         ` Pierre Ossman
2008-12-22 11:29           ` Adrian Hunter
2008-12-22 13:12             ` Bernd Eckenfels
2008-12-31 17:21             ` Pierre Ossman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4917EF03.8060308@nokia.com \
    --to=ext-adrian.hunter@nokia.com \
    --cc=Artem.Bityutskiy@nokia.com \
    --cc=drzeus@drzeus.cx \
    --cc=jarkko.lavinen@nokia.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox