From nobody Wed Jan 10 19:30:28 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T9Hvm3B10z55j1t for ; Wed, 10 Jan 2024 19:30:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-25.consmr.mail.gq1.yahoo.com (sonic304-25.consmr.mail.gq1.yahoo.com [98.137.68.206]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T9Hvk5tNWz4W5b for ; Wed, 10 Jan 2024 19:30:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=na0dLWSN; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704915041; bh=GT77XT+mkupWaLyhr1bw/0CJHwT/LuzZC+HdU6I0zH8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=na0dLWSNBgTIY4dgmpyrHGIYTvXfU5j17TVY9/utBJGIItau2RUsfj7v7KkgC2APHiFquFRzlbIHR+YD5RAAA0OlQB6kX9TLxrxliAozwNUJiTOCgiBNo+cUPIypPdu6+gewfRqjxJEjK654kEenP1I2qMas6bzIxHG7Nn7P+LyZfKP9ImdQAIZJb1R184zV7EJqcxb5Xn6zsBhB25Zr3/Md2Y3x0soRctFJhYDao5c+6zLRcMuMB+P5FQEsyfIeVD8u7nIkJVM8sJ6BDNOoRf3p+L6zYDIp1E/GrGxQ5G3E7VpzK2Tu3inQPK4nMRTlJtjSr6Iw4w+r3dXEnahfAg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704915041; bh=8Zch1r3ojW3ydySiS4QholkbnxhHz+5Cp9pZN6kxr+e=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=JAzIoO2lfjo3q9ibDgk76KWNTycO5mrow+GzVZwfxBUmtrqdaxqQK4qQioBkEo03b1TiWAlWaSEDBvGO3MxL4hk5yY8IEvGDUUVEAHjD6o6XNtN7qi0OhKTLZTisGawQc4Zb2vO3FLkvbfHYB3FLSD6OQDROBbk58pdVgAM5qtvvjtLM21Iv/tbaFShGsDvUh80Ipqb6jaerWvpFk7tQdcIRW6OjepUJ15iet/V/0uD4lUsINZAWF9Q/3wJNyM1gQGbijh0ZljrQyCqxn0/Cd2UsEq0nlS976IDU6PCjI5WGVDgLNjcbMgf5Y6bfhw3gIW8ITVG3Sc2GeMRXCLpINA== X-YMail-OSG: PmzVidEVM1nPf0ZqEAxRm.h_Wc8lTEv_7nhI6AKl3xKJo9UdSlB5FzudyyCJgKP 4rmkT7MmjaSSaJ4sfYk91F5Nv2wcKOV6PpJeHcOAHFQVOSJ8kXw4IAkD48F1kq3utnzLlOsF10zS FgZHuAGPk.YBzcAwNIrBqzOX6A222OJIFfP.9oFwllICgezBAdaT7fpHllssmpDX3Gp77AnA7HxL G_CGeU.aTA6L.X19vrsiQEwvAtu3NxVCRbiuLj5kECnnE4IKVWcm7GqtOvfnOsGqh6iYzBH46CC6 xuKpLbydd0WakjU9ikTAHByXPw5IIOIKMRq7OPR0k88Y9uqiaJlRxQ8uEcmvtnV7pmqNoEwaTPaz UGMhYzEYruks0NoMCm_1kd7m6IFIp8uex4rf807JrqSXKc32YbIDRBpVyipk6DtoLeASzWxZhPKG 0V7MN_hgTLfMMPQTOQmLaXH8dTyFN_jwDexax5FBZjC71gVJK84vg4JSJKo.F2bwFwWs0O_.cWUG meMo.7S_kuvfFjIUk3OmQFY8osoGVDrxuMsC9Q4jwgx68Op882pRLU6iVNm33i5QPSoKCM5csR3q LaoGLFFU028r4G5d8E3YdxXuK.hbLAA7k8ly38Ga95fB56857cr.JJw4eNsfh1kR6prKOpMv61ni _p0SpXEPLlPUxHSuX7OkcLnS7qMUamD3b5YFQlNttZCmv.UzSaOmmPx1u7E3UO3EoxuSqWVCsHUs uqCxEX.kNSXyNnDQCSfu6xk5Hbn0Hofb3miTnIHJM9xBBQHR8PIQlTz0W0GA4h6qBTFnVFgbGx_E x._qtFNiXd9LZj_5mYkCaBit6JgyWMSUYsiRZCIRGeNREy_AgZI9ESTETkMBuit.ZoNPMOdZZPyb 2gaonFnZlQAiO8S1.5bEHh1pZoLw_uoeBexl9hMeVfLl.8UV4gWMwsDN2QzT15Cipp5LBjn534.Y G33OR8tTUmR3BX05eu9x7oF_s08WmqzmZu_3.j7RsfZs3I4U2mogy3KBu7rbGU5F8DMtTHOydRRT eCpRKShc0IvhBH4h3b9sZn08nYwa_RbCH8pChW45QxdYQqjlXFzOhg.IEpxJwdObg06xohzoza8X 50N2zAC5qeo7TRmKhYh8dJyCHCmSBls.EATup6tUW7e2ZllsTpZmN0RUAabR.gEJYPm49rKqeYDz aG_WZaFbIyxfw_FxuzY1PkcPK6v5tI.W0keRxeOuQ9CuNXwO2uTERZAm2Rbr7tAnBwn0Z7zMxexh gWvw1EE7nf6Hie.pDugtLB8obVe4.X8E265TTb4Wn_ZB5SiOCJbbv1NJZCBVjnW7zFEZ.oeymNw7 MmkE2HswiH.aQZzbmf_Rw_v.2hsbB4sqwuxa6rU1EvWNBvXm8YB95Nq.K7eJ6jfjwikJHGGnb0zT zKX9pEpiRQeCKmYCwMYtW7EhifoO0F2ZsQ.T6f9gwk1PI5spiskZFzgsXLYcReiAuZHZtshwkUyx frYZl9rt_MCq7eo31GFSgCaRRg9pVnp4qlxnwQpCcFksQl5CoEzTt.Jde_OXGEJIwddEmhfzopdN riFDTMryLGSPqjrO4mhack0B8K0nDNImsNvU54gkSEwUm5P4ElChbLYvX9SgkXSx11Da1LqtLjBY Jukvnt818QfGVYXjoQuR4VHYn5m53OIV787gjMW6Png0LaKxMZ1V.PW38wA0zPbdGyPM9Djrfpv8 dyMGbUcbjEbDvB0nlWhgfZ9d.wPBfbCQt5.umLmRviL3fPVZZ9wJrYqZrUP0d7K2AOiDAnWGv9ch q3Wa4U_tKAsyTC9CY55VnT1WxpFAiPLL.JnhFI0k2uO6kL_ZCuT39Lf_CxsCzigixJc5kBKIcV8y TcuYqr2CzXp7Uxy1aPa8_5FaL2T5U_HSWafKBZgHT7c.UTUd3GZOV_mW_WRqumtBjYLTN6szMtFO tSw8.VJaSSf.G06TcVfmKcu3W5Jw1qExDQkys5pa_ggGN44R9Ffok1s.br_JyFQtAQPcTAdek7iQ sBfGRf_UEc_nNXSwLa1lNfr9TZ7sOJ8ZV3CM44hREJOR3npWQbCUYpBWcCQrTMkqU35_ICptGYK5 FCW.18Xrwlk3VjgkCsA1kU3_9CDhgXhTumN0CNdJVQ_FcAmfJ60KzoBLO6XxLUBdbYovjADlTegp sEMF5FmDzXCbgbIpwGWjoeD0od9GEIL5_zWRwogKkVw_mEOhQwKH2ckaxodixOnD5Nw_S.dB0leI 7BpHATukIi5gXPbHcytXTPDHotatT9dsEIVeqJGL3UKPUxCFJ4dmfamEV5yKzoOAo_hO4LzkC0g- - X-Sonic-MF: X-Sonic-ID: 466b9ecb-e3d5-4b50-9e64-9eb63904bf1f Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Wed, 10 Jan 2024 19:30:41 +0000 Received: by hermes--production-gq1-78d49cd6df-hlpbq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4540a0106e9a961ba0bb06249ff512a3; Wed, 10 Jan 2024 19:30:39 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: USB-serial adapter suggestions needed From: Mark Millard In-Reply-To: Date: Wed, 10 Jan 2024 11:30:28 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <55AC6824-587D-4C67-B64B-2045A1112F69@yahoo.com> References: <7D27DF9F-AA9A-4D44-BC28-8CC637D0F550@yahoo.com> <3012A549-9482-4D69-9DF4-7987E650DFFA@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.206:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.206:from] X-Rspamd-Queue-Id: 4T9Hvk5tNWz4W5b On Jan 10, 2024, at 11:21, Mark Millard wrote: > On Jan 10, 2024, at 10:16, bob prohaska wrote: >=20 >> On Tue, Jan 09, 2024 at 05:03:42PM -0800, Mark Millard wrote: >>> On Jan 9, 2024, at 14:47, bob prohaska 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