Beaglebone Black: crash during portsnap extract

[Mattia Rossi]

Am 21.02.2014 16:41, schrieb 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.
>
>
Interesting, as I was actually going to  complain about a similar (the 
same?) issue.
I've this problems on the dreamplug, and the internal SD card gets 
corrupted each time after using portsnap.
I'm not getting any panic though, it just gets stuck. Funny thing is, 
that even if I have a NFS share mounted or a ZFS pool mounted at 
/usr/ports (and /var/db/portsnap/ or any other specified portsnap 
working directory), portsnap manages to kill the filesystem of the SD 
card (why is it even touching it?)
It doesn't happen with any other copy or extract command like cp, scp, 
tftp, tar etc.
I didn't check for any timeout messages then though.... maybe I should.

Mat