Re: SDHCI: timeout during data transfer

From: Pierre Ossman
Date: Sat Oct 18 2008 - 16:47:06 EST


On Tue, 14 Oct 2008 23:13:39 +0200
"Luca Tettamanti" <kronos.it@xxxxxxxxx> wrote:

>
> I finally managed to capture a failure with debug enabled, I'm
> attaching the log.

It seems to be a transfer error at least as it is in a completely
different area of the card compared to the first mail you sent.

> To recap:
> - heavy write loads sometimes result in a timeout
> - reads seem unaffected (I read the card multiple times without errors)

Looking at the dump, the controller seems to be doing the correct
thing. The timeout mandated by the SD specification is 250 ms, and that
time has passed if you look at the timestamps. If you look at some
other writes further down, the card takes around 220 ms for the writes.
IOW, it would seem that this card is cutting it a bit close and
sometimes goes over the alloted time.

> - doubling the timeout (as per my first patch) makes the timeout disappear

Since it is the card that's the problem here, not the controller, we'd
need to fix this in the core. Unfortunately the sdhci hardware is a bit
inflexible so any change I make will result in a doubling of the
timeout.

Could you try modifying line 283 of drivers/mmc/core/core.c where it
says "limit_us = 250000;" to 300000 instead?

> - windows doesn't suffer from the issue

Windows doesn't do proper handling of timeouts. It just sets the
maximum timeout and hopes for the best.

>
> I've tested two other cards that do not show the problem, but they are
> not "high speed":
>
> mmc0: new high speed SD card at address 0002 (troubles)
> vs:
> mmc0: new SD card at address e624 (OK)
>

What's the vendor and model of the failing card?

--
-- Pierre Ossman

Linux kernel, MMC maintainer http://www.kernel.org
rdesktop, core developer http://www.rdesktop.org

WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/