Date: Tue, 30 Sep 2014 04:34:44 -0700 From: John-Mark Gurney <jmg@funkthat.com> To: Ian Lepore <ian@FreeBSD.org> Cc: freebsd-arm <freebsd-arm@FreeBSD.org> Subject: Re: Random Kernel Panic on Dreamplug (FS related) Message-ID: <20140930113444.GV43300@funkthat.com> In-Reply-To: <1411998551.66615.328.camel@revolution.hippie.lan> References: <542559BC.7090100@gmail.com> <20140929040126.GG43300@funkthat.com> <1411998551.66615.328.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
Ian Lepore wrote this message on Mon, Sep 29, 2014 at 07:49 -0600:
> On Sun, 2014-09-28 at 21:01 -0700, John-Mark Gurney wrote:
> > Mattia Rossi wrote this message on Fri, Sep 26, 2014 at 14:19 +0200:
> > > This might be part of the weird FFS issues the Dreamplug has and no-one
> > > knows why they're happening.
> >
> > Are you running w/ FFS journaling? If so, try turning it off, but
> > keeping softupdates on..
> >
>
> It's not an SU+J problem, or even an SU problem. fsck finds
> non-existant errors on filesystems known to be clean, and if
> write-enabled it will corrupt the good filesystem when attempting to
> correct those "errors". This is on armv4 only, not v6. I tested with
> and without softupdates on. I tested with UFS1 and UFS2 filesystems.
> You can even do a newfs followed immediately by an fsck on it and it
> will corrupt the fs.
>
> The one thing I haven't done is opened a PR for this.
Hmm... I just tested this on my AVILA board, and I don't see this on
either UFS1 or UFS2... Are you doing this via HD or md? My testing was
via a 64MB md as I don't have a good way to attach external storage to
my board...
If you really are seeing immediate corruption to an SD card, then I'd
make sure that the card is getting the correct data written to it...
I'd suggest trying to run ZFS since it checksums everything it writes,
but not sure if it'd run, and if so, how well...
> > > data_abort_handler() at data_abort_handler+0x5c0
> > > pc = 0xc0de7a28 lr = 0xc0dd711c (exception_exit)
> > > sp = 0xde019898 fp = 0xde019a20
> > > r4 = 0xffffffff r5 = 0xffff1004
> > > r6 = 0xc3f3f6c0 r7 = 0x00001000
> > > r8 = 0xc443e880 r9 = 0x00000000
> > > r10 = 0xc3d69000
> > > exception_exit() at exception_exit
> > > pc = 0xc0dd711c lr = 0xc0d53828 (ffs_truncate+0xaa8)
> > > sp = 0xde0198e8 fp = 0xde019a20
> > > r0 = 0xd0238120 r1 = 0x00000e60
> > > r2 = 0x00000000 r3 = 0x00000000
> > > r4 = 0x00000120 r5 = 0x00000000
> > > r6 = 0xc3f3f6c0 r7 = 0x00001000
> > > r8 = 0xc443e880 r9 = 0x00000000
> > > r10 = 0xc3d69000 r12 = 0xd0238120
> > > memset() at memset+0x48
> > > pc = 0xc0de521c lr = 0xc0d53828 (ffs_truncate+0xaa8)
> > > sp = 0xde0198e8 fp = 0xde019a20
> > > Unwind failure (no registers changed)
> >
> > No more beyond this? If you could run addr2line on 0xc0d53828 so
> > that we know where in ffs_truncate it's failing, that'd be very
> > nice...
> >
>
> Some time in the past 4-6 weeks something has gone wrong with kernel
> stack backtraces. Sometimes you get a full useful traceback, and more
> often it ends at the function that triggered the exception, always with
> a "no registers changed" message.
>
> -- Ian
>
> > > The sad thing is, that with fsck broken for the dreamplug, I have to
> > > re-format the disk, reinstall everything and recreate the config files
> > > which I didn't manage to copy to a safe place beforehand :-(
> > >
> > > Before I do that I'll leave the system in debugging mode for a few days,
> > > in case someone can help and needs some more information.
> > >
> > > Cheers,
> > >
> > > Mat
>
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140930113444.GV43300>