Re: enabling powerd on RPi
- In reply to: Mike Karels : "Re: enabling powerd on RPi"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Thu, 04 Jan 2024 16:50:06 UTC
On Thu, Jan 04, 2024 at 07:53:12AM -0600, Mike Karels wrote: > On 28 Dec 2023, at 13:11, Mike Karels wrote: > > > > If no one objects, I will make changes to enable powerd on RPI snapshots > > for 15-current, and we can see what happens. > > My change to enable powerd for all 64-bit Raspberry Pi systems using the > arm64-aarch64-RPI image is in https://reviews.freebsd.org/D43296. There is > also a review that splits RPi4 from RPi3 (etc); it is > https://reviews.freebsd.org/D43141. Comments welcome. > This certainly isn't an objection. Using powerd on Raspberry Pi versions 2, 3 and 4 is a noticeable help in speeding up things like buildworld. There does appear to be a peculiar interaction between ssh, powerd, tip and the serial console on Pi2, 3 and 4 which if verified might imply trouble of some sort. There's a thread on usb serial adapters regarding the issue. It's been my practice to put a usb-serial adapter in each Pi in my cluster so as to provide terminal server service to another pi in the cluster. The serial adapters monitor GPIO pins 8 and 10 on successive Pis in the cluster. This makes all serial consoles conveniently accessible via ethernet/ssh. When powerd is enabled on a given Pi, the ssh connection to its terminal server often drops, usually within a few hours, more quickly if the Pi is loaded. It's unclear where the disconnect originates, the only hint seen is a "broken pipe" message on the ssh client end. Attempts to use debug options on ssh and ucom aren't enlightening, at least to me. Turning off powerd seems to let the ssh connections last indefinitely, often for weeks. While the connections are working, there's no corruption of traffic, as one might expect from a baudrate mismatch. When a failed connection is brought back up, there is sometimes garbled output, some of it mistaken by the monitored console as input and intercepted by the login prompt as input. Once the line is "flushed", operation is normal till the next disconnect event. As it happens, the ssh client machine is a Raspberry Pi4 running Raspberry Pi OS. I don't think that's relevant, but it might be. Both PL2303 and FT232 usb-serial adapters are affected. The Ethernet side includes a D-Link DI-524, admittedly ancient but otherwise trouble-free so far. Avoiding use of the mini-uart didn't suffice. If someone more competent could try using usb-serial adapters to monitor the uart of another Pi (both running FreeBSD) over ssh it might shed some light on the phenomenon. Very likely it's an error on my part, if not it might be of significance. The apparent leakage of data onto the secure console input is undesirable, at best. Thanks for reading, and for FreeBSD. bob prohaska