Date: Fri, 3 Aug 2018 09:03:22 -0700 From: bob prohaska <fbsd@www.zefox.net> To: Warner Losh <imp@bsdimp.com> Cc: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>, bob prohaska <fbsd@www.zefox.net> Subject: Re: RPI3 swap experiments (insufficient swap) Message-ID: <20180803160322.GA6825@www.zefox.net> In-Reply-To: <CANCZdfpishDTo%2BQOKSvKNemFZJz4zLxtTKMdWJu=A6d=KVLXVw@mail.gmail.com> References: <23793AAA-A339-4DEC-981F-21C7CC4FE440@yahoo.com> <20180731231912.GF94742@www.zefox.net> <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com> <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <20180803010932.GA4321@www.zefox.net> <CANCZdfpishDTo%2BQOKSvKNemFZJz4zLxtTKMdWJu=A6d=KVLXVw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Aug 03, 2018 at 02:49:57AM -0600, Warner Losh wrote:
> On Thu, Aug 2, 2018 at 7:09 PM, bob prohaska <fbsd@www.zefox.net> wrote:
>
> > In the end the console carried a stream of what look like hardware errors
> > referencing
> > da0, but all was forgiven after reboot and a couple cycles of fsck -fy. An
> > excerpt
> > is in the readme file.
> >
>
> Unless the OOM is somehow killing a kernel thread, these errors are the
> root cause of all the crazy. Something happens along the way and we find
> that our error recovery to that something is bad and we never complete more
> I/O to the device (if I read the earlier thread right). No good can come
> from this.
Is it not odd that when OOMA acts prematurely no errors associated
with da0 make it to the console?
> The OOM is then doing weird things, but when the device goes
> away we're pretty bad at coping right now. The question, though, is how can
> we improve the USB / umass parts of the stack to do enough error recovery
> so we can survive whatever glitch that's causing it to stop talking to the
> device (and/or avoid that glitch in the first place). The disk/ssd isn't
> really bad, but we have some bug either in the USB host adapter, the USB
> stack, or in the umass SIM (or some combination).
>
Can you suggest any experiments a naive user might perform to help identify
the culprit? There's also a Pi2 running 11-stable available. Right now it
has storage set up like so:
bob@www:~ % gpart show da0
=> 0 122544516 da0 BSD (58G)
0 4194304 1 freebsd-ufs (2.0G)
4194304 4194304 2 freebsd-swap (2.0G)
8388608 6291456 4 freebsd-ufs (3.0G)
14680064 107864452 5 freebsd-ufs (51G)
bob@www:~ % gpart show mmcsd0
=> 63 15523777 mmcsd0 MBR (7.4G)
63 102375 1 !12 [active] (50M)
102438 1994714 2 freebsd (974M)
2097152 13426688 - free - (6.4G)
It could be given extra swap partitions on mmcsd0 so as to mimic the
insufficient swap problem on a 32 bit system. The Pi2 is known to suffer
the premature OOMA kill problem, it's never been subjected to a deliberate
run-out-of-swap condition.
Might there be something in the stress2 test suite that would be more revealing
more promptly than -j4 buildworld?
Thanks for reading!
bob prohaska
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180803160322.GA6825>