From nobody Thu Jan 18 22:11:03 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 4TGH5K5sjSz57758 for ; Thu, 18 Jan 2024 22:11:17 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147]) (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 4TGH5K0G7dz3xBp for ; Thu, 18 Jan 2024 22:11:16 +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=1705615874; bh=VMhRjYqBol1MKuQ9PDFJDFjX9CMXheDykaVVgWdDQZU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=L7KROwcQ31XTMb+nPTnqjNvHT2e1hIHfX3ITubvJduk5VBUTAAnTP9L+ghV7h+qPkOwqLeeokrHzmuvAQWX/LvwVDof4mbH2BqCzurQfVCiTOv3MrDEJF0csze31e0EnP27nbT52KzBoUzgralB3Mcf/E+1MCNfM+JsbR0PWbR5x97vzD2YjI41CdabIdqwdvuZ8ud+fapFROPAXHtmQLO1NWKqt+rr/vB/L450O3YW0uCTjnnX4oQlW4QLjjKIOTht9x/Epw5PLBnvB4nVpfvgCzx4twLKqFU4WVFy46gbhxQbRjCgFI7OwI7Qu7VUXrEt8+nGpNdCWisFDtDYLYA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705615874; bh=bOsq0Q2ABVaPxbbqH2rxgVov5zn9d7/h832J6Mu7pY7=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=NE/Pn8NgxBNItTCcR6xXxBq3Lj+jIenaCo1VDDN2mRMIy95F+jYAVU4d5Awpzt3aj3zoZQ2qsjDpeD0L8Kbq13ALZlr+FiGK2k1xbBDHv4TuXrdDLll2aTMFEvSextUgdLWsaZwPbzLYveTl+OxRe4Q74f5qUx32ugHtSNe88fpqlPXaSfJ2ZqbWbG7O5rDYX318/veVYBXwddAJhO4iVah2bzPAWQYvtdfCkDL8MHuU6MyhtV6XTczrHSDDas0edwKXqXgXleEA8Wh7DUDS+u/eUmDjUvuUlQTdlc9DcmT1JEUPCJupoBKWC/wXgEW7e21S20FcBsvXIbtdFcmp3Q== X-YMail-OSG: 0T2bHQYVM1ka4IY26LJgcVCqGoGaTFfcE5PllURCdC7ZiVbAlHrxtNNufRyma2F EwgHMEZS1aC0zu6GxEfhB7qpkFClWbj_f7jKld85hRjLKjgRkjL6DyQi1M7wVYX46yIzFm7kyLh7 IyiICn1Yytu7CxhxRlRmYQfbUvpTtR029eV9C.zPsJ0d33E_UkzNANA_m2LQbDv27Lfl1vxs5ax. AeoAPv0QreZxKy.UWSUHXfUNa3MyQnm6x6yRyGOKlS4VhVmKcyInxUgJz4fU_NNZHCaDtj3XETb8 cItfU0dGN_lNkUcQh6BhVwuTK_fK_gP4GFdC_fkM_UjjWBxIYRYz5q3pPWLoFCGvzi9AgfWht4EC T2VHvhdlz7iEm6B15WXWuGmWBuGnO5llxXgKBb5C0X9ylMgX13sR0KfE0V8BhegOUdgXHy3JTKPb PmW7gBfGMjyUkJc5KJN7k9yXJsfq23HIUulwDSgVkv.RHExYQ3F7fPH2GsjxzV5Au8Wg2ubjMd06 KxpiUHpU.Y3aUXOnfglAG2mBVLRQAFSky9qmEeswWzglZ3suFfbN.EckgXk.koRkaxCbcml8jBBa ZIvHDYhgpjNgI_ZRTutjttsJPLO0ZbdChue1RAYiq4Zc8mziemSYXJCYdNLGZw.uIvN5f0GVPw3j Jd_.iSyfP5NueKfhRe2CpTxtL338CtjQ0kUvCKb86WF6feEIrqZ_Sf.TO55dlaGjhyVfcfAzDtv_ EROhEnuUKxDHPBGJGL5ViJeZIhhHUeNklQgBIZaWsatIfU_1_u3q9Ij4ZxR_0.JypqM2AW7ROXvV .9RAmwLvxOnPymXAZfJTcjBK.4R3uU9rl1PLqbSDHaw5Qze9pKbx0YfdKVn_iGzz2Bxfo1Nbupct n5tgSjquw2OvzoDcsWw4S7sb4_Ez5LRN0zetXS3.ubebed1m3.iMZBnRiSukGedg5S_Gbsh4A9xY 88eOgHD.Q5PmZp26xUBSCr7gj2KHVKT2HETrJmHrGroXylWg7_XO_.zXb2xEoaf31dct3urpzzgT rg2suIu4peMNGyF0A96TyTsJBfeGn5ynsbdgn7z0H59HGGUnofbAd09eCXsHq2UCVZdVV9vNqCww 0aa7crI0rxprcjiQJ1g0wrlx_e_zeJr4V1XGaAGUyhQGvCKvuC6hvAjweQ7D5d8yqS_4jVqOcGD4 SbAut4HLRBCVEH97amasbPRyUMn8YBneBQli4ppi4fgrx_j_vmoG1IqevpLT8VbRjf9svgI4ClLl bCbOmy7VFbX590rT6AcLIfl5vn_sgXwPbjvwk8Gs.Jcotm3Jl.NoE7k04hPcSqK4z.Yqqk5LTDlR KYgE0vf65ai2pVwuUEXocNxx_xb10.Sh8QBKA5x.RCxbsnk641hRqMD7MzLvlKCzOm5jFluIWi2x fUMVfolUJKilQFZtF5Zwb3eL_lzYjO6n1s7hsMNp1XjmscnNenBIVCcbgnVttDkPRtOBQcrgwQYU LfqxOa7.Gi85ftJYENSVnP0q.EJpt1n_0NQ_u32vnukmCBF27M_TLtIsbsu9Puybz4KePp4kgnCK ab40pieGEzrUq1EjzL03L9fDG1lx.7XLkEay5IA9vEk.eghHOi4KcQE_mcruQ_Q_123Q4dqr3p0y Kz7iMZiRF0f9zLufiIByd9grrUqJ2078eMNcja_E7lby0WhK46bE8Tx5TR7SnU9kUL89RMwQwx3G yTndZBDL5Yd.6higjKJEV_WSJFcEk.HCx9qP_8AjFtp2FoMQZBIfbG1TyRdzOQr5Q2TCI69vlSgi 9EnZ11cwNEhsthNMM83pXv73CpBGn1Nm8vjRVbwmJkY9hnspdDqfXAxLZw8sZdRLAyl99sd7B3zp 8ksn1bX48M6iRTWwHF3E9xDACr6kgqWfvRHjSwqdg17mHoDoq482bAkg98u6aEKTuAO_Ht7R8bkv wAv93PfHXEJm6vRJqoKJo9Jns8Rbt1jzVTTkRCsskSY9Ou_6MqL9ALyo_I2ftUCwhnssnN_julo0 XpRzrmu9CHe8KwmjlJH3ADVnzWBy08UT7b1T9gKcF2Az6xrVEhxoaBeDI22gClsMgku4sB1jAWFC tttO4e96XE4Xn7uxTFdNG5bkW8rCDZkYSl.CovHNOPytFOkoStrFw3q1DW5UW90P4GCIc_JAALLW mZ6zS6QlKerLBhnKjxJf8lTfWPmIP4WrF_0ToY.SMyQqGNbtuflIdPBew0NXYTjvkJem06Mw41Pl DhKNHXGHJa6kLNAkps7IumZFoOXS8CAwQAlq0LnMB63Z3BtT60dU2EMGOs95B25dg9esfb9mzND7 rCg-- X-Sonic-MF: X-Sonic-ID: 79ef3b64-cc21-4973-9593-776b95ef1e30 Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Thu, 18 Jan 2024 22:11:14 +0000 Received: by hermes--production-gq1-78d49cd6df-xrrtm (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 227072b5e30a45561f9e6ab27196fedf; Thu, 18 Jan 2024 22:11:13 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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: sshd signal 11 on -current From: Mark Millard In-Reply-To: Date: Thu, 18 Jan 2024 14:11:03 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <7EF12F55-70E4-4780-BF73-3C7B963C3781@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Queue-Id: 4TGH5K0G7dz3xBp 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 18, 2024, at 11:32, bob prohaska wrote: > On Wed, Jan 17, 2024 at 08:22:50PM -0800, Mark Millard wrote: >> On Jan 17, 2024, at 17:51, bob prohaska wrote: >>=20 >>> On Wed, Jan 17, 2024 at 05:09:32PM -0800, Mark Millard wrote: >>>>=20 >>>> So far it sounds like the problem requires pi4 RasPiOS >>>> workstation behavior to be involved to get the problem. >>>> Can you do something to avoid all use of RasPiOS, possibly >>>> using a different OS on that RPi4B for some experiments? >>>>=20 >>> I just tried a Windows 10 laptop wired into the LAN. Ssh to=20 >>> ns2.zefox.net and running=20 >>> grep -i /var/log/messages produces five lines of grep matches,=20 >>> then "corrupted MAC on input....."=20 >>>=20 >>> I'm not sure which MAC (as in ethernet MAC) is being referred >>> to. Might a different kind of MAC exist, unrelated to ethernet?=20 >>>=20 >>> Running top, or cat /var/log/messages, produces the error >>> immediately. It seems safe to use ls. Meanwhile, the serial=20 >>> console session served by nemesis.zefox.com is still up=20 >>> and usable.=20 >>>=20 >>> I'm increasingly confused about where the error starts. >>>=20 >>=20 >> Note: I'm using unique switch naming below, something >> your diagram does not provide. >>=20 >> Both the macOS system and the pi4 RasPiOS workstation >> used the path (or so I assume): >>=20 >> MACHINE<->wifi<->lan<->router<->switchA<->ns2.zefox.net >>=20 >> What about the Windows 10 laptop test? Same path? >>=20 >=20 > I've edited http://www.zefox.net/~fbsd/netmap to reflect > the actual placement of hosts relative to the switches. >=20 >=20 >> Could a MACHINE with the problem be moved to be >> on switchA for EtherNet to see if it still has the >> problem when there (just for the test)? Testing the >> macOS system on switchA to be sure it still works >> could also be of interest. >=20 > If by MACHINE you mean the ssh client, pelorus.zefox.org=20 > is already there, along with ns1, ns2 and www.zefox.net. Given the new chart, I meant MACHINE by position in either ssh sequence: MACHINE<->wifi<->lan<->router<->switchA<->ns2.zefox.net MACHINE<->lan<->router<->switchA<->ns2.zefox.net You have an example of the later that gets the failure: MACHINE=3D"Win10 laptop" It means that involving wifi is not a requirement for the problem to happen. The fewer devices involved in the sequence that still show the problem, the better for the one type of evidence. This means I'm now focused on just: MACHINE<->lan<->router<->switchA<->ns2.zefox.net and possibly eliminating more stages as not required to get the problem. Now can lan and/or router be eliminated by moving one of "Win10 laptp" or "pi4 RaspIS workstation" temporarily? Moving to switchA would be testing not having either lan or router involved: MACHINE<->switchA<->ns2.zefox.net Does such a move lead to still having the MAC failure? To no MAC failure? (Switches, routers, and the like do sometimes have errors that mess up just some protocol, not everything.) > It's somewhat curious that going from RPi4 workstation > vi ssh to www.zefox.net and then ssh to ns2 does not > report corrupted MAC, but both machines run armv7 > FreeBSD 12.4.4 So, listing the nested(!) ssh sequence more fully, that was(?): "pi4 RasPiOS = workstation"<->wifi<->lan<->router<->switchA<->www.zefox.net<->switchA<->n= s2.zefox.net Or, being more explicit about the nesting: "pi4 RasPiOS = workstation"<->wifi<->lan<->router<->switchA<->www.zefox.net then, nested: www.zefox.net<->switchA<->ns2.zefox.net And it ends up getting the same result (no failure) as just doing: www.zefox.net<->switchA<->ns2.zefox.net without the involvement of any other MACHINE, if I understand right. Another related test would be by temporarily moving www.zefox.net to form one of: www.zefox.net<->wifi<->lan<->router<->switchA<->www.zefox.net or: www.zefox.net<->lan<->router<->switchA<->www.zefox.net Does such still not get a failure? Or does it then fail? > A three hop connection (RPiOS > www.zefox.net > ns2.zefox.net) > somehow inhibits the corrupted MAC error. Evidently > there's something special going on among the hosts. >=20 >> Could you boot a FreeBSD microsd card in the pi4 >> instead and try it as a FreeBSD system to see if >> it still has the problem (while in its usual >> place)? I'm still looking for the same hardware >> context but running a distinct but known OS >> context to see if the problem persists. >>=20 >=20 > Realistically I should probably just set up a microSD using > 14-Release and configure it as ns2.zefox.net. That is going a different direction than I asked about. It does not eliminate RasPiOS from involvement on the same hardware it was originally used on. Both types of tests have their uses. But my focus for now in this area is on the replacement of RasPiOS by a FreeBSD version to eliminate RasPiOS's involvement for some tests but using the same hardware as before the replacement (other than boot media). > That needs doing > anyway and should be done for www.zefox.net and ns1.zefox.net > as a matter of maintenance. =20 >=20 > The dilemma is then armv7 vs aarch64. Armv7 has served well, > and used to fit in 1 GB RAM. Now it's getting tighter.=20 > Aarch64 is _very_ tight in 1 GB RAM now and will doubtless > get worse. Is there a concensus on which to choose? I gather=20 > armv7's days are numbered but not up yet. armv7 is Tier 2 for 13.x and 14.x armv7 is projected to stay tier 2 for the later official 15.x ( stable/15 and such ) but might not. It is possible that armv7 might only be supported via lib32/chroot/jail use for aarch64 that also supports EL0 AArch32 --and so AArch32/armv7 could end up not being bootable any more by then. aarch64 is Tier 1 for 13.x and 14.x aarch64 is projected to stay tier 1 for the later official 15.x aarch64 hardware that does not support AArch32 at all would still be Tier 1. (The aarch64 tier 1 claims are somewhat strong for embedded aarch64. A possibility being that, at some point, a 1 GiByte RAM aarch64 might not be able to self-host buildworld buildkernel or various port->package builds even with substantial swap space --but that would not be likely to change the Tier 1 status of aarch64, for example.) =3D=3D=3D Mark Millard marklmi at yahoo.com