Re: USB-serial adapter suggestions needed

Reply: bob prohaska : "Re: USB-serial adapter suggestions needed"
Reply: bob prohaska : "Re: USB-serial adapter suggestions needed"
In reply to: bob prohaska : "Re: USB-serial adapter suggestions needed"
Go to: [ bottom of page ] [ top of archives ] [ this month ]
From: Mark Millard <marklmi_at_yahoo.com>
Date: Wed, 10 Jan 2024 01:03:42 UTC
On Jan 9, 2024, at 14:47, bob prohaska <fbsd@www.zefox.net> wrote:

>> 
>> For now all hosts run with powerd off in an attempt to 
>> re-establish baseline behavior. 
>> 
> 
> The baseline is proving somewhat bumpy. The ssh connection
> from workstation to terminal server pelorus.zefox.org (running tip to
> www.zefox.org) reported:
> 
> ...
> FreeBSD/arm64 (www.zefox.org) (ttyu0)
> 
> login: Jan  9 11:51:49 www sshd[24536]: error: PAM: Authentication error for illegal user scott from 85.209.11.226
> Jan  9 11:56:47 www sshd[24587]: error: PAM: Authentication error for root from 185.11.61.234
> Jan  9 12:32:28 www sshd[24748]: error: Fssh_kex_protocol_error: type 20 seq 2 [preauth]
> Jan  9 12:32:28 www sshd[24748]: error: Fssh_kex_protocol_error: type 30 seq 3 [preauth]
> Jan  9 12:32:52 www sshd[24752]: error: PAM: Authentication error for root from ool-2f104b1f.dyn.optonline.net
> Jan  9 12:32:54 www syslogd: last message repeated 4 times
> client_loop: send disconnect: Broken pipe
> bob@raspberrypi:~ $ ssh 50.1.20.24
> Password for bob@pelorus.zefox.org:
> Last login: Tue Jan  9 09:46:03 2024
> FreeBSD 14.0-RELEASE-p4 (GENERIC) #0 releng/14.0-n265400-4edf3b80733e: Wed Dec 27 20:21:26 PST 2023
> 
> [rest of MOTD snipped]
> ...
> bob@pelorus:~ % su
> Password:
> # tip ucom
> Stale lock on cuaU0 PID=1142... overriding.
> connected
> [typed Enter]
> 
> FreeBSD/arm64 (www.zefox.org) (ttyu0)
> 
> ...
> 
> Pelorus.zefox.org was idle at the time, www.zefox.org was running
> a -j4 buildworld and busy. Nothing was running powerd. The Pi4 
> workstation showed no other upset on any of the dozen ssh connections
> open at the time.

Interesting.

www.zefox.org is the aarch64 that is not configured in config.txt
in the normal aarch64 manor. As I've requested before, please test
using a config.txt that instead has:

QUOTE
[all]
arm_64bit=1
dtparam=audio=on,i2c_arm=on,spi=on
dtoverlay=mmc
dtoverlay=disable-bt
device_tree_address=0x4000
kernel=u-boot.bin

[pi4]
hdmi_safe=1
armstub=armstub8-gic.bin

# Local addition:
[all]
force_mac_address=b8:27:eb:71:46:4f
END QUOTE

Please do not use a configuration based in part on armv7 FreeBSD
config.txt material any more for the testing activity: Just use
the FreeBSD normal aarch64 configuration with the force_mac_address
related material added at the end.

I want to know if this also fails when powerd is not in
use anywhere.

[I assume that the "The Pi4 workstation" is the "pi4 RasPiOS
workstation". True? Presuming yes: Is the RasPiOS the 64 bit
variation? (Just my curiosity.)]

Do you run the buildworld on www.zefox.org and such via the
tip session on pelorus.zefox.org ? Via an ssh session from the
"pi4 RasPiOS workstation" to www.zefox.org ? More generally:

A) What runs (if anything) via the tip session started from
    pelorus.zefox.org ?

B) What runs (if anything) via the ssh session connected to
    www.zefox.org ?

A useful test would be to not have the tip command running
on polaris.zefox.org and to just use the ssh to www.zfox.org
instead to start the buildworld/buildkernel. So: No use
of the serial connection when the buildworld is started or
during the build(s). Using tip before that but quitting tip
before starting to load the RPi4B would be okay for this type
of test. The question would be if the:

client_loop: send disconnect: Broken pipe

still happens.

(I'm not claiming that recovery if it fails would be nice. But
finding out if it fails looks to be important.)

The contrasting useful test would be to start the buildworld
from the tip session on polaris.zefox.org and to not have any
ssh session to www.zefox.org . The question would be if a
failure of some kind still happens. (The tip session does not
have a pipe in use as far as I know so the detail for
identifying faulure would likely be different.)

Another question would be: do both such tests fail? Just one
(which)? None? So trying both tests eventually would be
important.

It is important to have only one of the 2 types of connections
in use during the buildworld/buildkernel and such activity for
this type of test --and only the one instance of which ever
type the active test is for.


===
Mark Millard
marklmi at yahoo.com