Date: Wed, 10 Jan 2024 11:30:28 -0800 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm@freebsd.org Subject: Re: USB-serial adapter suggestions needed Message-ID: <55AC6824-587D-4C67-B64B-2045A1112F69@yahoo.com> In-Reply-To: <E769A770-8D23-4EFC-8E75-F0ACF6705C4E@yahoo.com> References: <ZZoOMoM/iwcFqSNi@www.zefox.net> <7D27DF9F-AA9A-4D44-BC28-8CC637D0F550@yahoo.com> <C40967D3-D480-41DD-8054-421EA7AE5EFE@yahoo.com> <ZZy2FRO7MCOLMQhp@www.zefox.net> <DD96D1B0-92A8-4CBD-9661-FC86AC547405@yahoo.com> <ZZ2E8OZJBfXLkwQ%2B@www.zefox.net> <ZZ3NGeOtadKMHgIj@www.zefox.net> <3012A549-9482-4D69-9DF4-7987E650DFFA@yahoo.com> <ZZ7fBDxYd8Yyw5fm@www.zefox.net> <E769A770-8D23-4EFC-8E75-F0ACF6705C4E@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 10, 2024, at 11:21, Mark Millard <marklmi@yahoo.com> wrote: > On Jan 10, 2024, at 10:16, bob prohaska <fbsd@www.zefox.net> wrote: >=20 >> On Tue, Jan 09, 2024 at 05:03:42PM -0800, Mark Millard wrote: >>> On Jan 9, 2024, at 14:47, bob prohaska <fbsd@www.zefox.net> wrote: >>>=20 >> [transcript of ssh-tip disconnect omitted] >>>=20 >>> Interesting. >>>=20 >>> 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: >>>=20 >>> QUOTE >>> [all] >>> arm_64bit=3D1 >>> dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don >>> dtoverlay=3Dmmc >>> dtoverlay=3Ddisable-bt >>> device_tree_address=3D0x4000 >>> kernel=3Du-boot.bin >>>=20 >>> [pi4] >>> hdmi_safe=3D1 >>> armstub=3Darmstub8-gic.bin >>>=20 >>> # Local addition: >>> [all] >>> force_mac_address=3Db8:27:eb:71:46:4f >>> END QUOTE >>>=20 >>> 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. >>>=20 >>> I want to know if this also fails when powerd is not in >>> use anywhere. >>>=20 >>=20 >> I'd like to let the the present OS build/install cycle complete. >> Then I'll replace config.txt on www.zefox.org and reboot. >> That should be done in another day or two. The remote console >> disconnect reported above hasn't happened again, all consoles >> have stayed connected and responsive. >>=20 >>=20 >>> [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.)] >>>=20 >> Yes. Uname -a reports=20 >> Linux raspberrypi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16=20 >> BST 2023 aarch64 GNU/Linux >>=20 >>> 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: >>>=20 >>> A) What runs (if anything) via the tip session started from >>> pelorus.zefox.org ? >>>=20 >>> B) What runs (if anything) via the ssh session connected to >>> www.zefox.org ? >>>=20 >>=20 >> In general the tip session is used only for observation or >> troubleshooting. Ssh connections are used for other activity,=20 >> including OS build/install cycles, poudriere, etc. They are >> usually placed in the background, writing to log files so that >> accidental disconnects from the workstation don't stop them. >=20 > Are you using: >=20 > NAME > nohup =E2=80=93 invoke a utility immune to hangups >=20 > SYNOPSIS > nohup [--] utility [arguments] >=20 > DESCRIPTION > The nohup utility invokes utility with its arguments and at this = time > sets the signal SIGHUP to be ignored. If the standard output is a > terminal, the standard output is appended to the file nohup.out in = the > current directory. If standard error is a terminal, it is = directed to > the same place as the standard output. >=20 > Some shells may provide a builtin nohup command which is similar = or > identical to this utility. Consult the builtin(1) manual page. >=20 > ? >=20 >>> 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: >>>=20 >>> client_loop: send disconnect: Broken pipe >>>=20 >>> still happens. >>>=20 >>> (I'm not claiming that recovery if it fails would be nice. But >>> finding out if it fails looks to be important.) >>>=20 >>> 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.) >>>=20 >>=20 >> Normal practice is to leave the tip sessions displaying the=20 >> console host's login prompt. So long as the console login is=20 >> responsive I can assume that host isn't hung. >>=20 >>> Another question would be: do both such tests fail? Just one >>> (which)? None? So trying both tests eventually would be >>> important. >>=20 >> In general, ssh sessions behave completely independently.=20 >> Ssh connections to tip sessions commonly fail but no other=20 >> ssh connection to that terminal server is disturbed visibly. Silly me: The above is already the "ssh without tip" case and so is already covered. That just leaves the "tip not inside an ssh session" case to expirment with. >>> 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. >>>=20 >>>=20 >>=20 >> Apologies if I didn't answer your question; I'm missing the gist. >=20 > I only want one source of hangups/failure, no worries about which > one (network vs. serial) lead to the activity if a failure happens. >=20 > That only ssh sessions that in turn run tip fail suggests that the > tip session gets the initial problem and then things propagate. I > want more than a suggestion. For example: direct tip runs that > are not in any ssh session: still get some form of failures? Only the above needs a new experiment. > For > another: no tip use, just ssh: still get failures? The just above is already covered. > Do both ways > still get failures? Already known: no. > Yes, the implication is that some experiments that do not have > your normal structure are involved and there may be risk of not > being able to use a tip session as a responsiveness test during > such an experiment. I'm not suggesting any such thing for normal > operation once such experiments are finished. =20 Actually the no-tip case is already covered so the responsiveness testing is not an issue. >> It remains unclear where the disconnects to tip originate. >=20 > That is part of what I'm requesting exploration of via > different techniques than past attempts that did not provide > the information. >=20 >> If the tip >> session is stopped by typing ~~. from the originating ssh instance = I'm=20 >> returned to the shell on the terminal server. Ssh isn't disturbed. If=20= >> I type ~. the ssh session terminates and I'm back to the = workstation's=20 >> shell. Would it be informative to start a tip session, then ssh in=20 >> separately and try to kill tip? >=20 > A question is of SIGHUP is happening. If it is, then the kill that = would > simulate the issue would be via sending SIGHUP. But this may be only = one > of however many alternatives there may be. I prefer to explore what > is actually happening than attempted simulations via guesses at what = is > happening. >=20 >> I'd expect the ssh part of the link >> to remain up. If not, would it be significant?=20 >>=20 >> Occastionally warnings like >> Jan 10 00:23:30 ns1 sshd[925]: error: beginning MaxStartups = throttling >> show up in console messages. Might those be relevant in some way? =20 >=20 > Hmm. Intersting. Looking around I see notation like: >=20 > MaxStartups 10:30:100 >=20 > where (mostly copy/pasted wording from an example, other than detailed = formatting): >=20 > 10: concurrent unauthenticated sessions before it begins rejecting = some subsequent connections > 30: The percent of subsequent connections that are rejected [but see = below] > 100: At this many concurrent unauthenticated sessions, sshd rejects = all subsequent connections >=20 > Looking, "man sshd_config" reports: >=20 > MaxStartups > Specifies the maximum number of concurrent unauthenticated > connections to the SSH daemon. Additional connections = will be > dropped until authentication succeeds or the = LoginGraceTime > expires for a connection. The default is 10:30:100. >=20 > Alternatively, random early drop can be enabled by = specifying the > three colon separated values start:rate:full (e.g. = "10:30:60"). > sshd(8) will refuse connection attempts with a probability = of > rate/100 (30%) if there are currently start (10) = unauthenticated > connections. The probability increases linearly and all > connection attempts are refused if the number of = unauthenticated > connections reaches full (60). >=20 >=20 > It does suggest that testing isolated from the source(s) of > unauthenticated sessions could be worth while in case handling > the load from such sessions when already heavily loaded with > buildworld/builkernel or the like leads to other problems (and > denial of service consequences?). >=20 > I do not expect that this issue is all that likely but > expectations are not evidence of their own accuracy/inaccuracy. =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55AC6824-587D-4C67-B64B-2045A1112F69>