From nobody Wed Jan 10 19:21:39 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 4T9Hjf1jYTz55h4t for ; Wed, 10 Jan 2024 19:21:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-55.consmr.mail.gq1.yahoo.com (sonic308-55.consmr.mail.gq1.yahoo.com [98.137.68.31]) (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 4T9Hjd53Q5z4VGW for ; Wed, 10 Jan 2024 19:21:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704914514; bh=q+6vrdiX9o/19nwr2fh3N34PmiqHGOx39rv0hkcebX4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=G3FLH3OSyUgTBdjVvIagBQfP7+q8M299AMovIPQW0xF2yevixl4tlBWUtaVq8gLvk1qAOVWk8zypqDeT18gagXtm7goh2v4EXV9+Wnr3JF3hgFqCCKUOuInG1a1DDM216/qOF6jPpNsPUTZo5tDbPA6u8acIYtKrWeZfZrmJsZ6JjNiChmgom20NX/X4TnSU6T4ZKhKXBsZJggN8Ss9asSf4MD/DB6vZHySsmQlALkhkW5P+RCV4Qn2m+hLJ0jBexVDBwq1NWAAJXsHgIiOei6AtxFO/1ttIw9KqdVLXRrnNQ6TEAK459LQvEX0RZUeQGB7zgCjGMOct7jsQloaHFw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704914514; bh=ARdflYsO00Xka56WRctzLn3+n9W9JbpLj9xfsdU/QUL=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=KtLAjdIyXaQvf3/huHXUR8ohqQ04JDDUr9jYS5e1nYTLD1j5vuPz7FJHkY9BdWHwfbum9awMEzehrU+IYKs5jpJhCXu3YfxpcgtCRprLd/pAEFBXi2ovpQzqCYrhtcEdy9VLEopTp/bcPK9W9cEu2+fpYMuCh7gjfLBZW7OeHNrxjl9GJQYgO2PHSdcwZdkeEqbOi+FMuxBteDSNs4d+YaLvCK2DkJLPerFUKvDDBiKuHionJ/WRvbIBBoOB5D2t8VJwJEkCCLsAIKuKsXQ9far12b2y7ZntBAOYhStZN1h0Nc+Zil2JNasP+FiaIQp2uS9R4NzqOAot5icDdd6nvw== X-YMail-OSG: 22MzCwQVM1mpCUnouNa1vt4boVH9ijhkw6y79F.uV0skT8o6m5hnKJaim04ksA3 oGhufYPQHmZKipf5nbPUIgJC4P_a9VyrlWEPUI1IXFfftrHiby5xAkMfQDTtnWKRzZ4tBjXOgH.I JEjFCo0DzK9kVNUyv7ERwAw6fhKgpNAp0oH0M4Nb9JPn2MV22NnDAoUQFJ6IlOj9Q2xanuiB4gTZ 5350xA_Mz.ZXHNsTJIkZ5L_5XvZAkzCj2qpD_mfJtJF6PV5PA5bOnF1qLOFwQmUyDVOCSOpLBJWo lNX2AzH28ZLLOhCs1tfb3zlTLZir6oaIP0Cpxqlw4sZxNy3OajIqk64uklMu8Nx_kvvmeiOiiSgv VC7cdmq9hauUn.Kk5jvwyIATbKD4WuYSpNDaKKO2pwDtgM1UKykzkThjqzDGbZxSbuCIBR26DxCO ySmvZa9NMbHNXzRE5sOPFmnn8ZsAx0zcT81AghF1uGRlNGJqEVpjpS2zHFt9f11rbzS374LRZUpo P1vaZKDZSTQoJR3SXp9pMMEZ0M6weLYr.tAQSGd5mL3AHhjnGesoHOo4TuZIQ4YOG11UkRWwrkeQ rFAkKmWrL6h_pfhcbMs3f35ueoLPm_amGqHMp4uaHXZJdhkHcph7huvwpCZ8XWkyZbP50l13TWlu 5dwpn2SlkFM3ZG6eYERbUn16QOfII4OJj8wF3SOhJ9PlQyhKCkM7P4KwUG502079PSB332uTONeS E6iZJNpFMFKvU07ALhg1ZDVi7XO6DUJQj2WDgM_D.ZfOqyxX8Wvmva82FLJMKfvXYOVOvFvPjNuM ExekdTwgzEFHLrm3IsTUumu4y819_PjW_09kOxQuonYJQwL.A5xIq4jjlsOMbNRjxDJv2yhMAPk3 cgARYtK3uHfH3Dk._9tLwi44eOPJUEbPj6xcFggyY16G_u._GKOcHPAlITCz.BKE3ZPqAwsBH4lG pnyRaQhCC8U_38Hc7QJR_zzDlAb48drsGpT.JOxtfCXqOr8UkE0bvsp_NBv23uPyhD7XBmzeMTkN k7FFzo5.a7H7EFuQuvf4cCqCwnIZzuHCVxDRoka2WMZjp.szCjOEJo6Sb8zhppq0vRtcBcHDzaEM 3Ty5SA5MnX46_MvcL4Ea1ko9DSXaYO7Ls46eXroMbV3R0He2VqceE9oOs8X5_4Yil29T6Ly4p.ox KLzBQQ6v.gnw4qeg_NJpKA05vjrtds_Lss7A6kWon548gnUIP.kWKSTbHgYriWi2Hy94HMR782V9 0mkiogOth0XbH6JSjvXOah8x70AuYNRF1W38RMhXrHWjSen83DsMC84iHDca5NGmJQ9zTm8GYUcn HEjZ.fzzNhIXUccWBR34UlCslKmkepYhcL_qUrVPnXTrXxTky8vTHGTG9caf6d5_oLOAFBT6BKwh FigrKKLndn7eR2j8kkkIyNg7MCv5lI7ZkTVpFmfAx4MXHvLZh48Wu.DEJGyGJkvAQSH4PxQDoq4U N0i2VTUCM_.h4WeiS_5a8T5Dc4u_jyJ_HdrL4eBRUSBKWhevIeNvkWwauLiIqHB0ta6hvd51DWSF 2MrUv7LrPNPl223czXpzRVUPGYFgNVfj9Gr3UrUF4JWqSls1j1G42PjDpPXXJmS5abfm3sxx9p92 qaYEW1QdGmfnWIn35.K9d6RcsYhAKfPKsjvpAWlvXSWfaGEH6lKD2XP0p7OgrfVTCPtnjy608j5X fwezMkVTxtclcvPofaEufwAb.ucosmeAu1jSsUzE4ij7xE4L5T4MCefThK0l7yIKNSlvgPyo9eop yAKoDOJKfTmCRABOxgH0zm9IbprbIOsNE.BxOBHhlcmqia26kHpjdIzJJUz2z0OlIBLoFMayOPwp AGsDk4D.1JS7vRZf7AClW7eoYyw3Fc2ui8AMAKZwleaoPmvdxYBSCt6rwj9MW1k2ixpeSp4eVHTJ Lyb8ONA6WFShMuj.OY_gw9DakfvqQk5bJQiZVu9UjxRlsxVQXdbb4X4WAas81THXftpLbXH803LS RrrHMIvN1c3vDdmJB9sV8cfpJJx.meZ8wO4p0TEH4ygVF5dNFIDf9PWKi8OEZbE1I4VNF7_glrcd gNr544YC4zM1jU6A1L_Fr4cJjxgx.f1RRlnxKOUr0Vcd1Vr1wCIrG0xYUcQvNKMz5ZP3MISztwiN HRR8QkZUsxozQSPzHtimxN.UYc_sU8fwFbO3gfYf3JhcOtnBLnwFiFvzEqiHRm1cYbM.oKe20uws 9BrluhKmIrCBOzK2S0_IPhZsyP22Yi6vySmEsP5urEFV1hNc0MRfxA2yumh8lnfhvhsxQe03E X-Sonic-MF: X-Sonic-ID: b7e5793f-8050-43d1-89a8-f7a9aebff942 Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Wed, 10 Jan 2024 19:21:54 +0000 Received: by hermes--production-gq1-78d49cd6df-szbbq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID f3c76bab60cda1d9049cb4d123eff51c; Wed, 10 Jan 2024 19:21:50 +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:21:39 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: 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-Rspamd-Queue-Id: 4T9Hjd53Q5z4VGW X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Jan 10, 2024, at 10:16, bob prohaska wrote: > 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. Are you using: NAME nohup =E2=80=93 invoke a utility immune to hangups SYNOPSIS nohup [--] utility [arguments] 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. Some shells may provide a builtin nohup command which is similar or identical to this utility. Consult the builtin(1) manual page. ? >> 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. >>=20 >> 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. I only want one source of hangups/failure, no worries about which one (network vs. serial) lead to the activity if a failure happens. 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? For another: no tip use, just ssh: still get failures? Do both ways still get failures? 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. > It remains unclear where the disconnects to tip originate. That is part of what I'm requesting exploration of via different techniques than past attempts that did not provide the information. > 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? 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. > 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 Hmm. Intersting. Looking around I see notation like: MaxStartups 10:30:100 where (mostly copy/pasted wording from an example, other than detailed = formatting): 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 Looking, "man sshd_config" reports: 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. 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). 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?). 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