Beaglebone Black: crash during portsnap extract

[Ian Lepore]

On Sat, 2014-02-22 at 01:57 +1100, Jason Birch wrote:
> I think `portsnap fetch` is sufficient to trigger this with the snapshots
> from Feb 16th.
> 
>     $ uname -a
>     FreeBSD beaglebone 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r261948: Sun
> Feb 16 18:05:23 UTC 2014
> root at grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/BEAGLEBONE
>  arm
> 
>     [ via ssh ]
>     # portsnap fetch
>     Looking up portsnap.FreeBSD.org mirrors... none found.
>     Fetching snapshot tag from portsnap.FreeBSD.org... done.
>     Fetching snapshot metadata... done.
>     Fetching snapshot generated at Fri Feb 21 00:01:19 UTC 2014:
>     226ed4090b222d40e48a3ad2f610dd81bef3c38f53deeb100% of   69 MB  659 kBps
> 01m47s
>     Extracting snapshot...
>     [ Halts here ]
> 
>     [ Over in the UART world ]
>     mmcsd0: Error indicated: 1 Timeout
>     mmcsd0: Error indicated: 4 Failed
>     mmcsd0: Error indicated: 4 Failed
>     ... [ 30 identical lines omitted] ...
>     mmcsd0: Error indicated: 4 Failed
>     mmcsd0: Error indicated: 4 Failed
>     mmcsd0: Error indicag_vfs_done():mmcsd0s2a[WRITE(offset=998113280,
> length=16384)]error = 5
>     panic: No b_bufobj 0xc11d0c20
>     KDB: enter: panic
>     [ thread pid 12 tid 100007 ]
>     Stopped at      $d:     ldrb    r15, [r15, r15, ror r15]!
>     db> c
>     Uptime: 6m57s
>     Automatic reboot in 15 seconds - press a key on the console to abort
> 
> I see the same behaviour performing `portsnap fetch` over the UART
> connection. There's some trace/proc/reg love at
> https://gist.github.com/jbirch/9135611, but I'm afraid I don't know much
> more here. This is reliably reproducible so I'll be using it to learn how
> to effectively use ddb.

I recognize this, because a mistake of mine is involved... it got a
timeout based on new timeout logic I added in r261945.  As part of
trying to recover from that I made the code do a controller reset, and
that was a mistake, it leads to "everything after that fails."  I fixed
that in r261983, which does a lighter-weight reset that may let the
controller recover and subsequent retries will work.  I'm not saying
updating to r261983 will fix everything, but it's more-correct code.

What this doesn't explain is why it's getting a timeout in the first
place.  No single sdcard transaction is supposed to take longer than 250
milliseconds according to the SD spec.  When I was testing with this
stuff a few days ago, I had a 16gb card that was sometimes taking
between 1-2 seconds to complete a write command, but the commands were
completing successfully after that much time.  I tried a samsung 8gb and
a sandisk 4gb card and they worked fine.  It made me wonder if the 16gb
card was maybe some sort of grey market counterfeit.

-- Ian