From owner-freebsd-arm@FreeBSD.ORG Fri Feb 21 15:41:48 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5D1C6901 for ; Fri, 21 Feb 2014 15:41:48 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2DE791C14 for ; Fri, 21 Feb 2014 15:41:47 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WGsEO-000Kjq-O0; Fri, 21 Feb 2014 15:41:40 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s1LFfbpr032912; Fri, 21 Feb 2014 08:41:37 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19i49ZFTw4NNWbvBm+Qj8I5 Subject: Re: Beaglebone Black: crash during portsnap extract From: Ian Lepore To: Jason Birch In-Reply-To: References: <87ob2gxfg0.fsf@gmail.com> Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Feb 2014 08:41:37 -0700 Message-ID: <1392997297.1145.88.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 15:41:48 -0000 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