On 20/09/10 15:37, ext Ghorai, Sukumar wrote:
-----Original Message-----
From: Adrian Hunter [mailto:adrian.hunter@xxxxxxxxx]
Sent: Monday, September 20, 2010 5:20 PM
To: Ghorai, Sukumar
Cc: linux-mmc@xxxxxxxxxxxxxxx; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx;
Adrian Hunter
Subject: Re: [PATCH] mmc: failure of block read wait for long time
On 20/09/10 11:57, Ghorai, Sukumar wrote:
Adrian,
-----Original Message-----
From: Adrian Hunter [mailto:adrian.hunter@xxxxxxxxx]
Sent: Monday, September 20, 2010 1:24 PM
To: Ghorai, Sukumar
Cc: linux-mmc@xxxxxxxxxxxxxxx; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx;
Adrian Hunter
Subject: Re: [PATCH] mmc: failure of block read wait for long time
On 14/09/10 08:15, ext Ghorai, Sukumar wrote:
Adrian,
[..snip..]
[Ghorai] Adrian,
Yes this works and reduced the retry by 1/4 (2048 to 512 times for
1MB
data read) form the original code;
Initially it was retrying for each page(512 bytes) after multi-
block
read fail; but this solution is retying for each segment(2048
bytes);
1. Now say block layrer reading 1MB and failed for the 1st segment.
So
it will still retry for 1MB/2048-bytes, i.e. 512 times.
2. So do you think any good reason to retry again and again?
If you have 1MB that is not readable, it sounds like the card is
broken.
Why are so many reads failing? Has the card been removed?
You might very rarely see ECC errors in a small number of sectors,
but more than that sounds like something else is broken.
[Ghorai] yes, one example is we remove the card when reading data,
Well, that is a different case. Once the card has gone, the block
driver
can (and will once the remove method is called) error out all I/O
requests without sending them to MMC. That doesn't happen until
there
is a card detect interrupt and a resulting rescan.
[Ghorai] here we are discussing two problem,
1. If IO failed how to stop retry; because of -
a. internal card error
b. issue in Filesystem, driver, or host controller issue
c. or cards removed.
2. And 2nd how to sync block-layer IO, if card removed,
a. case 1: when card removed interrupt support by the platform
b. case 2: when card removed interrupt does not support by the
platform?
A possible solution is to put a flag on mmc_card to indicate
card_gone
that gets set as soon as the drivers card detect interrupt shows
there
is no card (hoping that we are not getting any bouncing on card
detect)
and then have mmc_wait_for_req() simple return -ENODEV immediately if
the card_gone flag is set. Finally, if the mmc block driver sees
a -ENODEV error, it should also check the card_gone flag (via a new
core function) and if the card is gone, do not retry - and perhaps
even error out the rest of the I/O request queue as well.
[Ghorai] your idea address the 2.a case, but not 2.b, 1.a, 1.b
The card removal case can be extended to use the bus ops detect method
when there is no card detect irq. I will send a RFC patch.
With respect to 1.a:
- If the card has an internal error, then it is broken. The user
should remove the card and use a better one. I do not see how
reducing
retry delays really helps the user very much. Arguably if the card
becomes unresponsive, the MMC core could provide a facility to
reinitialise the card, but that is yet another issue.
With respect to 1.b:
- The file system cannot cause the block driver to have I/O errors.
- If there are errors in the driver they should be fixed.
- If there are hardware problems with the host controller, then
it is up to the host controller driver to deal with them e.g.
by resetting the controller. I don't see what this has to do with
the block driver.
You leave out the important case of ECC errors. I am concerned about
this because of the possibility that it happens inside a file system
journal e.g. EXT4 journal. Perhaps the journal may be recovered if the
error only affects the last transaction, but perhaps not if it destroys
other transactions - which could happen if the approach you suggest
is taken.
[Ghorai] Thanks lot for your descriptive answer.
1. Can you answer this? 2.b. case 2: when card removed interrupt does
not support by the platform?
As I wrote above: The card removal case can be extended to use the bus ops
detect method when there is no card detect irq. I will send a RFC patch.
2. Why block layer handling for inter-leave data? Can you give example
diver who is returning interleave data? And how to tell application that
buffer having interleave data?
I am not sure what you mean by interleave data, but file systems for
example
are free to map any block to any file, directory or file system object,
so a consecutive series of sectors may contain unrelated data. Up to a
maximum
size, the block layer merges I/O requests when the sectors are consecutive,
so an I/O request can also contain unrelated data.
[Ghorai]
1. I don't think so, FS know where data exists and where is the free space. Except oth cluster.
I was not talking about free space. I was giving an example
of why it is not possible to assume anything about what is in
an I/O request.
2. Where its mentioned in block media that for segment-x[i],x[j] data read fail out of all all requested segments form [1..n].
And I never gone through any driver/protocol, that retry the next i+1th segment where ith-segment is failed. And for that my suggestion is preferred.
The SD/MMC protocol does not indicate which sector has the error.
There is no possibility of trying the ith+1-segment because i is
unknown.
And the solution I was proposing to return the status of IO failure as
soon as possible to above layer; and handle the card removed interrupt
separately or any other issue in h/w or s/w or combination of both. Or
just think again when platform don't have the card remove interrupt.
So my patch addresses the 1st part
It is absolutely unacceptable to return I/O errors to the upper layers
for segments that do not have errors.
And for the 2nd part we can submit the patch anytime.
I can suggest a patch if you want but I am on vacation next week so
it will have to wait a couple of weeks.
And moreover we should not give the interleave data to apps, as we
don't
have option to tell application for the valid data.
[..snip..]
http://comments.gmane.org/gmane.linux.kernel.mmc/2714
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
