ssh sessions close spontaneously on rpi2

[Mark Millard]

On 2017-Nov-18, at 8:56 AM, bob prohaska <fbsd at www.zefox.net> wrote:

> It appears that something(s) are profoundly amiss on r325916 when running
> on rpi2.
> 
> With make -j4 clean running in /usr/ports, new ssh connections fail
> promptly after login. For example
> 
> ===========begin copy/paste===========
> bob at raspberrypi:~ $ ssh com
> Password for bob at www.zefox.com:
> Last login: Sat Nov 18 08:38:45 2017 from 192.168.1.20
> FreeBSD 12.0-CURRENT (RPI2) #9 r325916: Fri Nov 17 01:03:51 PST 2017
> To change an environment variable in /bin/sh use:
> 
> 	$ VARIABLE="value"
> 	$ export VARIABLE
> bob at www:~ % Connection to com closed.
> bob at raspberrypi:~ $ 
> bob at raspberrypi:~ $ ssh com
> Password for bob at www.zefox.com:
> Last login: Sat Nov 18 08:41:33 2017 from 192.168.1.20
> FreeBSD 12.0-CURRENT (RPI2) #9 r325916: Fri Nov 17 01:03:51 PST 2017
> You can use aliases to decrease the amount of typing you need to do to get
> commands you commonly use.  Examples of fairly popular aliases include (in
> Bourne shell style, as in /bin/sh, bash, ksh, and zsh):
> 
> 	alias lf="ls -FA"
> 	alias ll="ls -lA"
> 	alias su="su -m"
> 
> In csh or tcsh, these would be
> 
> 	alias lf ls -FA
> 	alias ll ls -lA
> 	alias su su -m
> 
> To remove an alias, you can usually use 'unalias aliasname'.  To list all
> aliases, you can usually type just 'alias'.
> bob at www:~ % Connection to com closed.
> =============end copy/paste============
> 
> Stopping the make clean session restores normal behavior. Long-established
> ssh connections seem  to keep functioning normally, three have stayed up
> overnight, though two restarts of the make clean session.
> 
> At the same time, the reports of attempted umounts of /dev seem to have
> stopped, although the make clean sessions still stop, with only a cryptic
> "2 errors" on the controlling ssh session. There's nothing on the console
> or in the message log.
> 
> Altogether this is rather disturbing and I'd be grateful for any insights.

[Be warned that the BPI-M3 context here is experimental
currently: official build support has been disabled
for now, pending the switch to Linux based DTB content.
(There is a committer waiting for that *.dt* source
to be in FreeBSD.) I've temporarily patched a few
things to keep my BPI-M3 builds going during the "not
supported" time.]

It may not be rpi2 specific but an example of a more
general armv7(/6?) issue:

Using -r325700 (on both the BPI-M3 and amd64) and a debug
kernel (but with DIAGNOSTICs disabled) I've discovered
that when I nfs mount the BPI-M3 from the amd64 and try a
recursive diff:

# mount -o noatime,hard,intr <local-address-here>:/ /mnt
# diff -r /usr/src/sys/ /mnt/src/sys/

the Ethernet connection on the BPI-M3 stops working:
existing connections time out and ping in and out both
fail. (The serial console still works fine.)

Via the serial console I can sometimes restart the
networking via:

# ifconfig awg0 down
# ifconfig awg0 up

but if the "diff -r" is still going when I do that the
BPI-M3 networking will quickly fail again.

No console messages, no core files.

So far this type of test sequence always fails in
a fairly short time.

[DIAGNOSTICS was disabled because with it enabled
the USB did not find USB devices and I normally
use a USB SSD for the root file system.]

===
Mark Millard
markmi at dsl-only.net