From: "Steffen Kühn" <sk@ammonit.com>
To: "ludovic.desroches" <ludovic.desroches@atmel.com>
Cc: Chris Ball <cjb@laptop.org>,
linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org,
Nicolas Ferre <nicolas.ferre@atmel.com>
Subject: Re: [PATCH] mmc: atmel-mci: fix deadlock
Date: Tue, 15 May 2012 18:05:25 +0200 [thread overview]
Message-ID: <4FB27EC5.70507@ammonit.com> (raw)
In-Reply-To: <4FAA4ADA.1080008@atmel.com>
Dear Ludovic,
in the meantime I have some new informations about the atmel-mci
deadlock problem: When you write permanently with
dd if=/dev/zero of=/dev/<device> bs=512
and removing the card you will get almost always a hang up. With
"printk" I have find out that the function "atmci_tasklet_func" doesn't
run anymore in this case.
I would ask you to add card inserting and removing during write and read
in your test cases.
Regards
Steffen
Am 09.05.2012 12:45, schrieb ludovic.desroches:
> Hi Steffen,
>
> Le 05/09/2012 11:23 AM, Steffen Kühn a écrit :
>> solves a deadlock problem which appears when a mmc card is
>> removing and a process is reading from the card at the same time.
>> ---
>> drivers/mmc/host/atmel-mci.c | 4 +++-
>> 1 files changed, 3 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/mmc/host/atmel-mci.c b/drivers/mmc/host/atmel-mci.c
>> index e94476b..effdc36 100644
>> --- a/drivers/mmc/host/atmel-mci.c
>> +++ b/drivers/mmc/host/atmel-mci.c
>> @@ -1499,8 +1499,10 @@ static void atmci_tasklet_func(unsigned long priv)
>> }
>>
>> if (!atmci_test_and_clear_pending(host,
>> - EVENT_XFER_COMPLETE))
>> + EVENT_XFER_COMPLETE)) {
>> + host->stop_transfer(host);
>> break;
>> + }
>>
>> atmci_set_completed(host, EVENT_XFER_COMPLETE);
>> prev_state = state = STATE_DATA_BUSY;
>> --
>> 1.7.2.5
>
> Even if it solves your issue, I am not sure about the consequences of
> this fix even if it is working well in your case and with your hardware.
>
> This condition allows to wait for the end of a transfer. The
> EVENT_XFER_COMPLETE flag is set when the dma transfer is complete (or pdc).
> If the transfer is not complete you will ask to stop it. I understand it
> could solve your issue but I am afraid it can also stop a transfer
> before its normal completion.
>
> I am currently working on atmel-mci and the state machine would be
> changed. So I prefer to wait the new atmel-mci version to take this
> patch. I will add your issue to my test cases.
>
>
> By the way, can you give me more details about your issue because I
> can't reproduce it on my side. If I remove the card while a process is
> reading from it, I also have I/O errors but I have no issue to detect a
> new card insertion.
>
>
> Regards
>
> Ludovic
prev parent reply other threads:[~2012-05-15 16:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-09 9:23 [PATCH] mmc: atmel-mci: fix deadlock Steffen Kühn
[not found] ` <4FAA4ADA.1080008@atmel.com>
2012-05-09 12:12 ` Steffen Kühn
2012-05-15 16:05 ` Steffen Kühn [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FB27EC5.70507@ammonit.com \
--to=sk@ammonit.com \
--cc=cjb@laptop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=ludovic.desroches@atmel.com \
--cc=nicolas.ferre@atmel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.