[PATCH] mmc: atmel-mci: fix deadlock

[PATCH] mmc: atmel-mci: fix deadlock

[Steffen Kühn]

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

Re: [PATCH] mmc: atmel-mci: fix deadlock

[Steffen Kühn]

Hi Ludovic,

my hardware is a multiprocessor system by which the access to the card
is shared between two processors. Because of this changes happen really
frequently.

I have observed that the deadlock only occurs when the card is
desappearing and there are errors like 'end_request: I/O error, dev
mmcblk0, sector XXX'. A process has to read permanently from the card.

The problem seems to be that the driver waits for finishing the
transfer, but this comes never because the card is unavailable. Maybe a
new state machine solves this in a better way as my workaround.

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

Re: [PATCH] mmc: atmel-mci: fix deadlock

[Steffen Kühn]

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