From nobody Sat Jan 06 18:07:24 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 4T6pFh3wqFz56rKG for ; Sat, 6 Jan 2024 18:07:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-20.consmr.mail.gq1.yahoo.com (sonic306-20.consmr.mail.gq1.yahoo.com [98.137.68.83]) (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 4T6pFh1Kdnz4lhw for ; Sat, 6 Jan 2024 18:07:36 +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=1704564454; bh=qq8srq6hpFzwa4FdMVVR4p2s2l/NjQtd8jwJnQTFWEE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=YsX8/GWPaeZQ5hkWQn6U0gd9eTrNZ/DfDFS1A66nx3cGky2nBtjQ0vBoA1+rOuCwir7Pkl2RyggO7PHdMFgSwXDCATc+eNTKCY0AFHGjmmIuMz3v79X4vj7M9opw+bm+kVmmKKuD/a9wng8jyvMaJbLVctb/mEMIth9AKIJSEjIh59jcP1YW+al6K6VRMLLaJjdZqAduVSJA7c8O/EdiGP5bvLl3JLjgLfi3S5NHlFHDPKJnaAWfWOQhgou9+gAbAQCIyj10UojZ3bnuc04ipbeF7HYlwpDs7ifHT9abst2qkoCxdilNSw29NSnaWzNTHRuCwADmVqthmsp3JQvj6g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704564454; bh=sXJrNC1pFybczWoQiMMXMS9szhbTGE/QkXiO5SW6IQn=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=NYD2DAEsckrEkiyQHbAUpIG2Iy7SdGYv4iPbwkUKKeOtNg+/IxrhAMHR5DWA9PL7KVtgyQXidS/bP4DKLSYNrrcSzKdMqOVJGZKJsfr7pkUtfd8MccdAzDZWKayXSofuNhMCLrpzW5WQjzhyiAQKz1QeLYLc8kq/gIAp8wItp7S0XHgkizPZnkDfYnexot7baEXhs3uiEDRIwrcjftlxHGdscHsX0prvR0FnvREIhIkL9ayHmEQliTFPJpBiuCTpJq08jsRbFYlbSP/anZtUjqHAiV4Za4vRK3wMGqgc/NT5fHw+rJol9ib/EFz4WD0qC79XWPaw6Uq5WUZXZpX7Tg== X-YMail-OSG: CMgszrcVM1l5FGyoB3O8U4T_eL88oeGWi9ots16.n3sq29L1yZGo0BJT0F_Oune hba7YBq8neQH5b4jVsKV0nye1O.s1IQkVeK_CHGqxYkhaV5dqYF.nTAqJrem01JlOoJbs7wljjB1 I2m893Uam4nzYJLJvpFxfcE3QxrJKD9p0TSsyXws0hPwIzzHQ82cbU5y8jMLocidbxyTgrdjaLzo xksBNxgD5I2j7w7YSS_uW48xvHUveuLsYPHrrwyPv96UvaSwH0DseQSW4sxp.MrN7dlBsB4mfya. CZWf9Xm8fSDSEFs5Y8xP8Pq4PbbTnD1HLqYxCqYSNMOV.P8Orb4P4Y_pBL5p0oKWK7QkptWSYXKW ENL.fWFo7NXrVteMnuKQcLD2RqjX5_gtCS8Vd08Z51c3LIGMqnVZSkt.MEXl9tAp3flQtP_Yg41t z4kEW_eAgMsvHgAA5k16fBjlD31hxhWlY8KxdteZfSQhJ2OYUzXKi8g2LbOr5JAHrlZvn4gVc8Zk 6ozoNSvEzPM0iJ.gFvKWxM5VbI2LQIsgO8vj5mzOq5rldoaAM3ynGULfcwJBilQcMlung.TIIPar D12TSWNb_QoFxjsF_fzm9l42._8LLzb1TMy6v1rK0dh0UatGUUIhiDIlaVhAOUIyzQrSu7GnhgMa Gf.dGgtdQe_ppGlh9.nQugz4lxtMRdMcvT2FVJ3QsOt0nX81mqhPBBR7Dd74j0xd4HZyyUOoL3Ht 4ncJA_BIpuHV8hqrp_0iOsawsgivwa_F7jClycTN6.2o9uxm3y54.oKeLaWf5LQmBNAFRbbPNa27 f8KSlAzGrGNX2UTR6AlNlnjaYeITKbzWUtPTpBgpty93YH3W9aY1ebVI1F.YeHx6o1kxq.sphtbI 2tt8X3reO9eAv6ePQQp5KMvkEcv.KfLuZTYzo2Hw5Yikm3F2Vh9q_UD6Qjy.T8PCfJHph2BNMZ90 4qp7pD6yEKZ62d33K4ajwYcE4vCt0CB_rHPxzWhqMrGmxrJWIF.uyhK4Iq5osSQl7xP_q5wi0S8_ 4ywP1.00gx4wU6XiQyWzAnxYjGJ5sgOppC0qNDhKLKLRuQEyoeYMxDuou9j8ARc0IRxMHpsfrseZ 8fdJcDC8U8XinvkF0_KVA5NYMt8lIx1aSlMLf6LM7rikmK.B6nNFyncWpuvp4CM5n.121tAXhBx0 9dyaNttppd6DpvvfbCwl00bkeuEj_nmDmCS3Tt0qivE9rSFfGbRw_tdAjRgxCq2LKS3vXJ2CJUCd OzUo4ntrLIwS4jco5X1Q1x3TFrAbrVm3hh2_I18MWNH3PxzSMRliwhRGxY0QXq_E1VPiA8WXs5Gd QXbBnCGPn2hdCi8zDso32unGBCn58zB0MKWdF7acKj1G9RcOx3Nkpml0_ItQahw0UGfjGL55rlDS J5RlH2s9ItoZwXU8q_Js_J2eN.xcDmUoVVDTSzj8zKFbWMmR5zlr8SNxWdtDoYjDL8uxbm8EV7oQ LUCQ4ugBjZ8dnySTfNExCdtf11QtnqqhApDOiOECXTAdRxMam9E9ohKT7nGw.2xctDvKMl_XSLnE oM0qkkZqhgPmt8vv7OX06C9bZxfO_tPjyQbJ94aJkDFg8266s4s88u66sMnzNS0HsFzdT3jtLcex OrZ5BOkH5fRn_C9RhWo38NsBFimQ4CuaJ_kAQxoeA2rNI03ot663EchUnCSiGX_ZR3q.B.KjNBfC jRNppWS_XEF_tniLaEEkKyUkkHAsvQqhTM0GTKtSbrwgO7KhYVr1V52Ic6HzBAFQi.RdA7gMYcso pS2gXbqPRsarQwzlF.KGO.wbwUqjX3hFSgzXDkT5TeS8BSpc0X28bmxV8dloqoYpZ7eVEzTrVL4. beeITaP0JFjThJNUn2aaQ1BTw7sPY3OeaWcraB3WFMBGOJOMebH52mlfdXBHchugdHNZMoM_aUzY 1eQPCSt4AwRDgATSCBFoX3u8Q49KXYzhlV_qsE8kWZ_mZg.Kh8dRTD1o5ZZlHFtcvn0UovfvWQP9 6UB5C5Kfq8wCZE2prhTRE0hhxvMay7DCoMJt2R.zqYQ1X315plvBrWhIHaKf23TLMMAfFRbJbFZG yGjd57JN6oJtXttrHl1.eTe5VrgaL28kww_WplCPlxddjH9OLtSqHLLH.bonWULDTLzMHQsKMaKe DOkMK.3LlzuOYZ49f26mCI1Tpbfe__clCiTnXIsTqlrfM2UAg.P6P8q_iDgK.3ypGs9zQEkzlc6w 6t4SpCM.VV08cmIMNU_MVDsMnejEDANF4NSriHUAA6x_4_xz4AQ-- X-Sonic-MF: X-Sonic-ID: 79aef9f2-b644-48d3-acfe-924033ca36c1 Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sat, 6 Jan 2024 18:07:34 +0000 Received: by hermes--production-gq1-6949d6d8f9-7dnvp (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4cbf90c7c85616e6c7c1d7a1b62a2d73; Sat, 06 Jan 2024 18:07:29 +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: USB-serial adapter suggestions needed From: Mark Millard In-Reply-To: Date: Sat, 6 Jan 2024 10:07:24 -0800 Cc: Marcin Cieslak , John F Carr , ticso@cicely.de, freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <9o7q7p36-o7pn-27o9-62no-8p1r6o127123@fncre.vasb> <849BD5E3-4C09-46CB-932D-ADC1B45F3C73@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Queue-Id: 4T6pFh1Kdnz4lhw 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] [Back to just some cell phone based internet access.] On Jan 6, 2024, at 08:33, bob prohaska wrote: > On Fri, Jan 05, 2024 at 07:26:16PM -0800, Mark Millard wrote: >>=20 >> I'd next try having powerd disabled only on the terminal server >> pelorus and then checking for getting a failure. >>=20 >=20 > I started powerd manually on www.zefox.org using > powerd -a adp (which I think is the default) > last night. The machine's console connection lasted all night. > Previously powerd was started via /etc/rc.conf. Might that be > somewhat different? >=20 > However, early in the evening I accidentally crashed the RPiOS > workstation, forcing me to re-establish all the console sessions. > When the connection to www.zefox.org came back up it was prefaced > by the usual non-printable gibberish. That session is still up > as I write this. Could the gibberish be the result of getty > activity on www.zefox.org as it establishes the connection from > pelorus (the terminal server)? Part of baudrate negotiations,=20 > maybe? Serial baud rates are not negotiated or automatically matched. The 2 sides are set separately but have to be kept in agreement from both sides. The send and receive directions have the same baud rate at both ends (when configured to work). One end is the tip end and the other end is via the GPIO pins on the other RPi* in this kind of context. Of course, things like Ethernet do have configuration matching. But that is a different context. > The overnight test was unloaded. Now www.zefox.org has been=20 > updated: Updating 499e84e16f56..aa1223ac3afc > with a -j4 build/install cycle running with 3.5 GB swap > divided between two USB mechanical hard disks. =20 >=20 >> Last I would try instead having www.zefox.org = be the only one >> of the two with powerd disabled. >>=20 > That test will come next, in a couple of days. >=20 >> I expect that having powerd disabled just on pelorus will prove >> sufficient and that having powerd disabled just on www.zefox.org = >> will not prove sufficient. >>=20 >=20 > So the difficulty is on the ethernet-usb-serial side?=20 > I was thinking it's on the serial-console side, maybe > an inadvertent escape sequence from baud mismatch. Lets just wait for the 2 experiments. My expectations are not valid evidence. I probably should not have said anything about my expectations. >> I also request to again list the exact content of the two >> config.txt files --and again every time they are changed during >> this investigation. >>=20 >=20 > On pelorus, the terminal server, config.txt contains: > bob@pelorus:~ % more /boot/efi/config.txt > [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 The above is what FreeBSD's snapshots for aarch64 provide. The below is not. (I'm igoring the needed force_mac_address line that is a required differnece.) > On www.zefox.org, the console client, config.txt contains > bob@www:~ % more /boot/msdos/config.txt > arm_64bit=3D1 > dtoverlay=3Ddisable-bt > init_uart_clock=3D3000000 > enable_uart=3D1 > kernel=3Du-boot.bin > kernel7=3Du-boot.bin > dtoverlay=3Dmmc > force_mac_address=3Db8:27:eb:71:46:4f I suggest you instead use the likes of: [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 [pi4] hdmi_safe=3D1 armstub=3Darmstub8-gic.bin # Local addition: [all] force_mac_address=3Db8:27:eb:71:46:4f (In this form the first 11 lines, if I counted right, are unchanged from the snapshot content. Note that earlier lines can be overridden by later lines in that local additions section.) I would prefer if the testing was based on having the uniformity instead of the existing varaibility in the config.txt files. > I'll admit to some uncertainty where=20 > init_uart_clock=3D3000000 > and=20 > kernel7=3Du-boot.bin > came from. Look at the official armv7 snapshot's config.txt content. It looks like you started from an armv7 config.txt instead of from an aarch64 one. I suggest that you make your aarch64 config.txt files uniform, other than things like force_mac_address being added where needed. This uniformity criteria would imply that if you discovered that some line was important for the serial console that it be supplied in all the aarch64 config.txt files, not just the one where the issue was discovered. > The latter seems harmless, but I'm > not so sure about the former. Judging evidence of sufficiency is easier for having uniformity where it proves possible. Otherwise there are more things to deal with and wonder if they contribute or not. >> You also have the option of fixed-rate clocking that is faster >> than FreeBSD default. This can be controlled from config.txt . >=20 > As a last resort, yes. Still, I'd like to minimize power use > to the extent possible. That gets into if the failures are infrequent enough that you can tolerate them and continue to use powerd for the power savings (presuming no other alternative is readily available that happens to work). Not for me to say. > Powerd seems optimized for laptops. > Maybe it isn't the right tool for mains-powered, lightly > loaded servers which occasionally see saturation loads. =3D=3D=3D Mark Millard marklmi at yahoo.com