On Wed, Apr 27, 2011 at 3:16 AM, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote: > On 26/04/11 16:19, Arnd Bergmann wrote: >> >> On Saturday 23 April 2011, John Stultz wrote: >>> >>> From: David Ding<david.j.ding@xxxxxxxxxxxx> >>> >>> CC: Chris Ball<cjb@xxxxxxxxxx> >>> CC: Arnd Bergmann<arnd@xxxxxxxx> >>> CC: Dima Zavin<dima@xxxxxxxxxxx> >>> Signed-off-by: Bentao Zou<bzou1@xxxxxxxxxxxx> >>> Signed-off-by: David Ding<david.j.ding@xxxxxxxxxxxx> >>> Signed-off-by: San Mehat<san@xxxxxxxxxx> >>> Signed-off-by: John Stultz<john.stultz@xxxxxxxxxx> >> >> The disable_multi logic was introduced in 6a79e391 "mmc_block: ensure >> all sectors that do not have errors are read" by Adrian Hunter. Maybe >> he can comment on this. >> >> My impression is that the code makes more sense without this >> add-on patch, because the flag is set for exactly one request >> and makes mmc_blk_issue_rw_rq issue all blocks in that request >> one by one up to the first error, while after the patch, >> we would read one sector, then read the remaining request at >> once, fail, and read the next sector, and so on. >> You could definitely interpret the retry path as being: - do a probe sector-sized read/write - if it succeeds, pretend everything is fine and retry with disable_multi=0 - else the probed sector must the point of failure ...it would mean more retrying in the case of an actual card failure mode (at which point you're not doing much anyway), and drastic improvement in the case of some one-time (or not so one-time) host glitches... The other thought I have is that it's not ideal to overcomplicate the logic inside issue_rw_rq (i.e. bisection stuff). Until Per's refactoring as part of async issue it was already too big :-). What do you think? Anyway I hope the patch owner weighs in. A -- 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
