Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 5 Mar 2014 22:48:19 +1100
From:      Jason Birch <jbirch@jbirch.net>
To:        freebsd-arm <freebsd-arm@freebsd.org>
Subject:   Re: Beaglebone Black: crash during portsnap extract
Message-ID:  <CAA=KUhtSw0mKd4V-7A7_5Dgqjis-NCSrH5509-j_fgUma0o-2Q@mail.gmail.com>
In-Reply-To: <CAA=KUhtKUAA65dcsgQYfj=-WeBHNN9RrbRQyK8=eEjt%2BUXTcvQ@mail.gmail.com>
References:  <87ob2gxfg0.fsf@gmail.com> <CAA=KUhut52brkbxTUZ%2Bis40GWy1nQKedfffyBg8V_bjqCOhXAQ@mail.gmail.com> <1392997297.1145.88.camel@revolution.hippie.lan> <53077971.8060406@gmail.com> <CAA=KUhtRprsSYLyhu4hZt9Cb0_v0uj%2BANiaaqLj5gkUXMY%2B%2Beg@mail.gmail.com> <CAA=KUhtKUAA65dcsgQYfj=-WeBHNN9RrbRQyK8=eEjt%2BUXTcvQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
I'm not sure the underlying problem is solved here -- I encountered it on
r262372 when compiling lang/perl5.16 overnight, and I see emails dating
back to at least September 2013 on r255438, which followed with a
discussion on what you can possibly do to recover in these scenarios.

In the mean time, I might purchase a faster SD card for use with my
BeagleBone Black as a cheap (effortwise) work-around, as I'm using a spare
Class 4 I had lying around.


On Mon, Feb 24, 2014 at 11:13 PM, Jason Birch <jbirch@jbirch.net> wrote:

> Henryk notes that this doesn't occur when just copying the tree around --
>> although that'll be many smaller files instead of one big one. I wonder if
>> it's specifically happening in conjunction with bsdtar -- I'll try and
>> contrive a testcase later this afternoon.
>
>
> I can't trigger this as a non-privileged user. I can reliably trigger this
> by a simple `tar xf /var/db/portsnap/<blah>.tgz` as root.
>
> I'm taking r262372 for a spin now (Which of course includes your r261983),
> and have been able to successfully extract the ports tree as root without
> being dumped into ddb. Though... I have been sitting here waiting for the
> snapshot verification for quite a while, but that's another story. The only
> thing untoward I see is that UFS lock order reversal...
>
> lock order reversal:
>  1st 0xc2f73394 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2101
>  2nd 0xcd25c3c8 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:262
>  3rd 0xc2f93934 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2101
>
> ... but I think that's well known at this point and isn't a cause for my
> concern.
>
> Thanks Ian!
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAA=KUhtSw0mKd4V-7A7_5Dgqjis-NCSrH5509-j_fgUma0o-2Q>