Date: Sat, 6 Jan 2024 10:07:24 -0800 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: Marcin Cieslak <saper@saper.info>, John F Carr <jfc@mit.edu>, ticso@cicely.de, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: USB-serial adapter suggestions needed Message-ID: <BE662AC7-EAE9-4032-8F5B-C1238726A1D8@yahoo.com> In-Reply-To: <ZZmA8D4DaVJJCjF6@www.zefox.net> References: <ZY4y2NvvL0N8Db69@www.zefox.net> <B7E5DF67-4B43-401A-89DC-6F9422C95FA9@yahoo.com> <ZZBIkRLZzYLZLsv8@www.zefox.net> <9o7q7p36-o7pn-27o9-62no-8p1r6o127123@fncre.vasb> <ZZCb1WA2sjtYhw13@www.zefox.net> <p0n4n675-22qq-9np2-96r0-s6o06253o450@fncre.vasb> <ZZgrLEFX5AUwgHPe@www.zefox.net> <849BD5E3-4C09-46CB-932D-ADC1B45F3C73@yahoo.com> <ZZmA8D4DaVJJCjF6@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[Back to just some cell phone based internet access.] On Jan 6, 2024, at 08:33, bob prohaska <fbsd@www.zefox.net> 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 <http://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 = <http://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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BE662AC7-EAE9-4032-8F5B-C1238726A1D8>