> -----Original Message----- > From: Chris Ball [mailto:cjb@xxxxxxxxxx] > Sent: Saturday, August 28, 2010 2:30 AM > 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 > > Hi, > > On Tue, Jul 27, 2010 at 04:57:46PM +0530, Sukumar Ghorai wrote: > > multi-block read failure retries in single block read one by one. It > continues > > retry of subsequent blocks, even after failure. Application will not be > able > > to decode the interleave data (even if few single block read success). > > This patch fixes this problem by returning at the first failure instead > of > > waiting for long duration. > > > > Signed-off-by: Sukumar Ghorai <s-ghorai@xxxxxx> > > --- > > drivers/mmc/card/block.c | 1 - > > 1 files changed, 0 insertions(+), 1 deletions(-) > > > > diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c > > index cb9fbc8..cfb0827 100644 > > --- a/drivers/mmc/card/block.c > > +++ b/drivers/mmc/card/block.c > > @@ -419,7 +419,6 @@ static int mmc_blk_issue_rq(struct mmc_queue *mq, > struct request *req) > > spin_lock_irq(&md->lock); > > ret = __blk_end_request(req, -EIO, > brq.data.blksz); > > spin_unlock_irq(&md->lock); > > - continue; > > } > > goto cmd_err; > > } > > -- > > Sukumar/Adrian, any thoughts on a new version of this patch containing > Adrian's retry-segments idea? [Ghorai] I am checked and tested the suggestion from Adrian. But was thinking it's just reducing the retry by 1/4 time; mean - 1. Each segment is size of 4K. and multi-block-write failed move to next segment(4k); 2. i.e. original code it was retrying for each 512 bytes. Now it's retrying for 8*512 bytes. So retry reduce by 1/8 times. So I will post the 2nd version as suggested by Adrian; but let's see others input. > > -- > Chris Ball <cjb@xxxxxxxxxx> <http://printf.net/> > One Laptop Per Child -- 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
