Date: Fri, 21 Feb 2014 08:41:37 -0700 From: Ian Lepore <ian@FreeBSD.org> To: Jason Birch <jbirch@jbirch.net> Cc: freebsd-arm <freebsd-arm@FreeBSD.org> Subject: Re: Beaglebone Black: crash during portsnap extract Message-ID: <1392997297.1145.88.camel@revolution.hippie.lan> In-Reply-To: <CAA=KUhut52brkbxTUZ%2Bis40GWy1nQKedfffyBg8V_bjqCOhXAQ@mail.gmail.com> References: <87ob2gxfg0.fsf@gmail.com> <CAA=KUhut52brkbxTUZ%2Bis40GWy1nQKedfffyBg8V_bjqCOhXAQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1392997297.1145.88.camel>