Announcing Q4D06 for XO-1.75

Sascha Silbe silbe at activitycentral.com
Tue Mar 27 08:51:44 EDT 2012


Excerpts from Chris Ball's message of 2012-03-26 20:36:21 +0200:

> > I'm specifically asking because recent kernels don't like my SD card
> > (only one in about twenty or fifty boots succeeds; two different
> > failure modes), so I'd need to make sure I diagnose and fix that
> > before upgrading OFW the next time.
> 
> That sounds bad, what are the failure modes?

The first, more common one is that the card is detected, but cannot be
read from:

[  664.720232] mmc0: new ultra high speed SDHC card at address e624
[  664.732502] mmcblk0: mmc0:e624 SD32G 29.7 GiB 
[  664.746219] mmcblk0: retrying using single block read
[  664.762748]  mmcblk0: p1 p2 p3
[...]
[  666.028453] mmcblk0: retrying using single block read
[  666.054195] mmcblk0: error -84 transferring data, sector 62333824, nr 8, card status 0x900
[  666.095591] end_request: I/O error, dev mmcblk0, sector 62333824
[  666.134176] mmcblk0: error -84 transferring data, sector 62333825, nr 7, card status 0x900
[  666.171475] end_request: I/O error, dev mmcblk0, sector 62333825
[and so on, for several thousand lines]

The second one is an error during initialisation:

[  664.702457] sdhci: Switching to 1.8V signalling voltage failed, retrying with S18R set to 0
[  664.718679] mmc0: error -110 whilst initialising SD card

The second failure mode is probably present even in "good" kernels.

For comparison, this is the output of a "good" kernel:

[    3.730914] mmc0: error -84 whilst initialising SD card
[...]
[   13.764283] mmc0: Timeout waiting for hardware interrupt.
[   13.794605] mmc0: Got command interrupt 0x00000001 even though no command operation was in progress.
[   13.910907] mmc0: new SDHC card at address e624
[   13.931460] mmcblk0: mmc0:e624 SD32G 29.7 GiB 
[   13.949543]  mmcblk0: p1 p2 p3


This is a UHS-I card and there have been a few UHS-related fixes
floating around upstream, so I hoped waiting some time for the fixes to
flow into the OLPC kernels would suffice.

git bisect blames the following OLPC commit:

39fc327e8d541d146528f03150fec36189e4dac5 is the first bad commit
commit 39fc327e8d541d146528f03150fec36189e4dac5
Author: Andres Salomon <dilinger at queued.net>
Date:   Thu Dec 22 16:28:55 2011 -0800

    sdhci-pxa: add retuning of timing in the case of CRC errors
    
    This is only for the !wlan devices.
    
    Signed-off-by: Andres Salomon <dilinger at queued.net>

:040000 040000 8491cdb303acbd02ff57aedb87692034bf5f0c3a 6539c5e378cad2515cff0de742f4f2c45436fa35 M      arch
:040000 040000 98a157c23be118fbd5df6dae5cdab93f3562db71 bd14b387a72156a605e15a7923e308bc9f5cb6e5 M      drivers


Tracked as OLPC#11736 [1] now.

Sascha

[1] https://dev.laptop.org/ticket/11736
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.laptop.org/pipermail/devel/attachments/20120327/ea16a242/attachment.sig>


More information about the Devel mailing list