From nobody Thu Jan 04 16:50:06 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 4T5XdJ092tz56lgv for ; Thu, 4 Jan 2024 16:50:12 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T5XdH40pSz4cVS for ; Thu, 4 Jan 2024 16:50:11 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 404Go63P075293 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 4 Jan 2024 08:50:06 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 404Go6Cf075292; Thu, 4 Jan 2024 08:50:06 -0800 (PST) (envelope-from fbsd) Date: Thu, 4 Jan 2024 08:50:06 -0800 From: bob prohaska To: Mike Karels Cc: freebsd-arm Subject: Re: enabling powerd on RPi Message-ID: References: <136EA428-CC30-4CF4-BE65-30B0CC8656AF@karels.net> 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <136EA428-CC30-4CF4-BE65-30B0CC8656AF@karels.net> X-Rspamd-Queue-Id: 4T5XdH40pSz4cVS 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:7065, ipnet:50.1.16.0/20, country:US] 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