linux-kernel - Re: SDHCI: timeout during data transfer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 18 Oct 2008 22:46:50 +0200
From:	Pierre Ossman <drzeus-mmc@...eus.cx>
To:	"Luca Tettamanti" <kronos.it@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: SDHCI: timeout during data transfer

On Tue, 14 Oct 2008 23:13:39 +0200
"Luca Tettamanti" <kronos.it@...il.com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/