From owner-freebsd-arm@FreeBSD.ORG Fri Feb 21 16:06:13 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 5E0D7675; Fri, 21 Feb 2014 16:06:13 +0000 (UTC) Received: from mail-ea0-x22a.google.com (mail-ea0-x22a.google.com [IPv6:2a00:1450:4013:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B8BAF1FA3; Fri, 21 Feb 2014 16:06:12 +0000 (UTC) Received: by mail-ea0-f170.google.com with SMTP id g15so1680352eak.29 for ; Fri, 21 Feb 2014 08:06:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=lkDeeQVkOWjn2GBPHYlOU1FB22CRZU172Wh6Xa1VZ6E=; b=H7rhWxjZEhicNdwtC7lwuKvoBQhYIemh+VV9VrzQNSnHeBJJPclxlY19zh0dH0XYMb iVSj0XXl2eJGFacGaXYy7SVkkVHgC6Z0b5t1FPeZaCBiBpQnDrXn5V3lfynegxhgaJAz /Ev4SFqwUi213+4S8SFS98xsSZWDhWHbynJ6C5MUNKYjxO03hEE29GTe1j26w9K5TNNW nJfV1X4jLfGqS+8opU7Oudl8TtIy6ulQZY6zwgYdqU6jQo0N4wX7sMSbesqdRCcJeJkJ ywyxFHjw3pbnBQfOaeW5Crlzmi70GR38GaU07q9s9ayyFZyE/XSu7fZW6Hrw4p0GSNSu d70g== X-Received: by 10.14.193.193 with SMTP id k41mr9324149een.112.1392998770992; Fri, 21 Feb 2014 08:06:10 -0800 (PST) Received: from [192.168.0.118] (vpn.static.83-173-212-209.cybernet.ch. [83.173.212.209]) by mx.google.com with ESMTPSA id j41sm27973640eey.15.2014.02.21.08.06.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Feb 2014 08:06:10 -0800 (PST) Message-ID: <53077971.8060406@gmail.com> Date: Fri, 21 Feb 2014 17:06:09 +0100 From: Mattia Rossi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ian Lepore Subject: Re: Beaglebone Black: crash during portsnap extract References: <87ob2gxfg0.fsf@gmail.com> <1392997297.1145.88.camel@revolution.hippie.lan> In-Reply-To: <1392997297.1145.88.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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 16:06:13 -0000 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@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