Date: Wed, 21 Jan 2009 10:05:33 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: krassi@bulinfo.net Cc: mav@FreeBSD.org, freebsd-arm@FreeBSD.org Subject: Re: Mount root from SD card? Message-ID: <20090121.100533.-1955669401.imp@bsdimp.com> In-Reply-To: <4977500A.7060902@bulinfo.net> References: <4977236E.2020409@bulinfo.net> <20090121.084023.188100520.imp@bsdimp.com> <4977500A.7060902@bulinfo.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <4977500A.7060902@bulinfo.net>
Krassimir Slavchev <krassi@bulinfo.net> writes:
: -----BEGIN PGP SIGNED MESSAGE-----
: Hash: SHA1
:
: M. Warner Losh wrote:
: > In message: <4977236E.2020409@bulinfo.net>
: > Krassimir Slavchev <krassi@bulinfo.net> writes:
: > Boot with verbose messages is here:
: >
: > http://mnemonic.bulinfo.net/~krassi/ARM/arm.verbose
: >
: >> This looks very similar to the data corruption I saw when I had
: >> enabled multiblock read. To track this down, we're going to have to
: >> print the actual data returned for each sector...
: >
: >> Warner
:
:
: Here is a dump of data right after the byte swapping in
: at91_mci_read_done():
:
: http://mnemonic.bulinfo.net/~krassi/ARM/sd.dump
:
: and here is the first 1M of the SD card:
:
: http://mnemonic.bulinfo.net/~krassi/ARM/sd.bin
Looks like we're getting some data corruption:
CMD: 11 ARG 0 len 512
ff ff ff ff fc 31 c0 8e c0 8e d8 8e d0 bc 00 7c
89 e6 bf 00 06 b9 00 01 f3 a5 89 fd b1 08 f3 ab
fe 45 f2 e9 00 8a f6 46 bb 20 75 08 84 d2 78 07
80 4e bb 40 8a 56 ba 88 56 00 e8 fc 00 52 bb c2
...
and then:
CMD: 11 ARG 0 len 512
00 00 55 aa fc 31 c0 8e c0 8e d8 8e d0 bc 00 7c
89 e6 bf 00 06 b9 00 01 f3 a5 89 fd b1 08 f3 ab
fe 45 f2 e9 00 8a f6 46 bb 20 75 08 84 d2 78 07
80 4e bb 40 8a 56 ba 88 56 00 e8 fc 00 52 bb c2
...
So it looks like the first 4 bytes are corrupted on the read. If you
look closely at the data on the device, you'll see that 'fc 31 c0 8e'
are the first 4 bytes of the reads are the 'left over' data from prior
data streams. This didn't used to be the case in the prior code
before the recent changes. The only way we're going to find the bad
change is to do a binary search on the svn changes to find out where
we go off the rails. This problem seems familiar to me, but I can't
quite put my finger on what the root-cause was last time I had it.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090121.100533.-1955669401.imp>