Hi Viresh,
I also meet the hang issue when suspending a system with a mounted SD card. Actually it caused by a dead lock of mmc_claim_host. Maybe we faced the same issue.
So may be the two mails in the attachment can help you.
Thanks
Chuanxiao
> -----Original Message-----
> From: linux-mmc-owner@xxxxxxxxxxxxxxx
> [mailto:linux-mmc-owner@xxxxxxxxxxxxxxx] On Behalf Of Viresh Kumar
> Sent: Tuesday, November 15, 2011 1:47 PM
> To: Chris Ball
> Cc: linux-mmc@xxxxxxxxxxxxxxx; Shiraz HASHIM; Armando VISCONTI
> Subject: Re: [Query] mmc/sdhci: Suspend hangs if card is inserted at suspend.
>
> On 11/12/2011 8:54 AM, Chris Ball wrote:
> > On Fri, Nov 11 2011, Viresh Kumar wrote:
> >> > Controller specific suspend/resume are still not called, so i think it might
> >> > be related to core code. I am using 2.6.37 kernel version.
> >> >
> >> > Any help on this?
> > Please try to reproduce on 3.1 and let us know if it's present there.
>
> Hi Chris,
>
> Support for SPEAr13xx is not present on 3.1 and it will take some time to
> move support there. I have a bit more info which might able you to guide us:
>
> file: drivers/mmc/card/queue.c
>
> static int mmc_queue_thread(void *d)
> {
> ...
> do {
> req = blk_fetch_request(q);
> ...
> if (!req) {
> if (kthread_should_stop()) {
> set_current_state(TASK_RUNNING);
> break;
> }
> up(&mq->thread_sem);
> schedule();
> down(&mq->thread_sem);
> continue;
> }
> set_current_state(TASK_RUNNING);
> mq->issue_fn(mq, req);
> } while (1);
> ...
> }
>
> - In normal cases, i.e. when we are able to stop this thread,
> req is returned as NULL from blk_fetch_request()
> - Suspend hang only occurs when the card is mounted.
> - When suspend hangs, req is not returned as NULL and the card is
> already removed by kernel and so we never check kthread_should_stop().
> So it hangs.
>
> --
> viresh
> --
> 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
--- Begin Message ---
- Subject: [RFC]mmc: fix dead lock issue when system entering S3
- From: "Dong, Chuanxiao" <chuanxiao.dong@xxxxxxxxx>
- Date: Tue, 17 May 2011 15:53:52 +0800
- Cc: "He, Bo" <bo.he@xxxxxxxxx>
- Reply-to: "Dong, Chuanxiao" <chuanxiao.dong@xxxxxxxxx>
- Thread-index: AcwUaQLOgUV7ksPURUqFKBbWIoSJ+Q==
- Thread-topic: [RFC]mmc: fix dead lock issue when system entering S3
- User-agent: Mutt/1.5.20 (2009-12-10)
Hi all,
I encountered a dead lock issue. Two threads try to claim host, unfortunately
one thread needs to sync with the other. I encountered this issue with SD
card when testing system entering S3. Does anybody encounter the same issue?
Environment:
1. without CONFIG_MMC_UNSAFE_RESUME operation
2. the SD card mounted
During system tried to enter S3, mmc_pm_notifier will be called first to remove
SD card. So calling sequence in SD remove thread is like this:
mmc_claim_host
bus_ops->remove
....
....
mmc_cleanup_queue
kthread_stop(mq->thread)
...
...
Mean while, mmc_cleanup_queue wakes up mq->thread, the calling sequence in mq->thread is
like this:
mmc_queue_thread
mq->issue_fn (mmc_blk_issue_rq)
mmc_claim_host (dead lock)
....
....
Since mmc_claim_host is called in mq->thread (not SD remove thread) again,
unfortunately right now host is already claimed by SD remove thread which is
also waiting for mq->thread finished, so cause a dead lock here.
Move the mmc_claim_host(in mmc_pm_notifier) after bus_ops->remove can resolve
this dead lock. mmc_suspend_host() is using the same way to claim host.
Need to know your suggestions.
Signed-off-by: He Bo <bo.he@xxxxxxxxx>
Signed-off-by: Chuanxiao Dong <chuanxiao.dong@xxxxxxxxx>
---
drivers/mmc/core/core.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 68091dd..1e27588 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1850,11 +1850,10 @@ int mmc_pm_notify(struct notifier_block *notify_block,
if (!host->bus_ops || host->bus_ops->suspend)
break;
- mmc_claim_host(host);
-
if (host->bus_ops->remove)
host->bus_ops->remove(host);
+ mmc_claim_host(host);
mmc_detach_bus(host);
mmc_release_host(host);
host->pm_flags = 0;
--
1.7.3.4
--
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
--- End Message ---
--- Begin Message ---
Hey,
On Tue, May 17, 2011 at 5:03 AM, Dong, Chuanxiao
<chuanxiao.dong@xxxxxxxxx> wrote:
> Just found Andrei Warkentin also submitted a RFC patch, which included more fix for mounted root file system media. Please ignore this thread.
I submitted an RFC patch as an idea up for discussion, but certainly
the issue never went away :-).. Your patch will not quite work. If you
have a filesystem it will not unmount, so mmc0 (for example) will
never release, so when a new (or same) card re-enumerates, it will be
mmc1...
I believe my patch basically created "md orphans" which would be
reconnected on resume, which is bit of a really nasty hack... I'm not
sure if there is a better way. I could have sworn I saw a patch a week
ago that attempted to resolve the suspend/resume with mounted fs issue
by deferring removal until resume, but I don't see it now, and I'm not
sure if it dealt well with the whole attempting to unmount fs in mmc
block cleanup path...
I guess I can resubmit...
A
--- End Message ---
