On 19 May 2015 at 08:32, Justin Wang (王丁) <Justin.Wang@xxxxxxxxxxxxxx> wrote: > From 05849da563c80c20597ab6275d5881a8ed426f96 Mon Sep 17 00:00:00 2001 > From: justin.wang <justin.wang@xxxxxxxxxxxxxx> > Date: Mon, 18 May 2015 20:14:15 +0800 > Subject: [PATCH] mmc: card: Fixup request missing in mmc_blk_issue_rw_rq > > The current handler of MMC_BLK_CMD_ERR in mmc_blk_issue_rw_rq function > may cause new coming request permanent missing when the ongoing > request (previoulsy started) complete end. I think you need to elaborate a bit more here. In exactly what scenario does this problem occur? > > This would cause the process related to the missing request stay at 'D' > state forever. 'D' state? I suppose it waits for a response for its IO request. Doesn't also the block layer complain or timeout somehow? Would be interesting to know a bit more about what really happens when things goes wrong. > Seems like we should have a fixes tag here as well, could you possibly try to find what commit that introduced this bug? > Signed-off-by: Ding Wang <justin.wang@xxxxxxxxxxxxxx> > --- > drivers/mmc/card/block.c | 8 +++++--- > 1 files changed, 5 insertions(+), 3 deletions(-) > > diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c > index 60f7141..f05cd1f 100644 > --- a/drivers/mmc/card/block.c > +++ b/drivers/mmc/card/block.c > @@ -1910,9 +1910,11 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue *mq, struct request *rqc) > break; > case MMC_BLK_CMD_ERR: > ret = mmc_blk_cmd_err(md, card, brq, req, ret); > - if (!mmc_blk_reset(md, card->host, type)) > - break; > - goto cmd_abort; > + if (mmc_blk_reset(md, card->host, type)) > + goto cmd_abort; > + if (!ret) > + goto start_new_req; > + break; > case MMC_BLK_RETRY: > if (retry++ < 5) > break; > -- > 1.7.4.1 > Kind regards Uffe -- 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
