Re: enabling powerd on RPi

From: bob prohaska <fbsd_at_www.zefox.net>
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