Beaglebone Black: crash during portsnap extract

[Jason Birch]

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 at 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!
>