RPI3 swap experiments (insufficient swap)

[bob prohaska]

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