From nobody Tue Nov 28 20:27:20 2023 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 4SfvC42xxmz52VsR for ; Tue, 28 Nov 2023 20:27:28 +0000 (UTC) (envelope-from sr@genyosha.net) Received: from ns0.genyosha.net (ns0.genyosha.net [50.39.243.220]) (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 "float.home.genyosha.net", Issuer "float.home.genyosha.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SfvC40Cz4z4dMt for ; Tue, 28 Nov 2023 20:27:27 +0000 (UTC) (envelope-from sr@genyosha.net) Authentication-Results: mx1.freebsd.org; none Received: from dragon.home.genyosha.net (ops0.genyosha.net [50.39.243.219]) by ns0.genyosha.net (8.17.1/8.17.1) with ESMTPS id 3ASKRQnp007984 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 28 Nov 2023 12:27:26 -0800 (PST) (envelope-from sr@genyosha.net) Received: from dragon.home.genyosha.net (localhost [127.0.0.1]) by dragon.home.genyosha.net (8.14.7/8.14.7) with ESMTP id 3ASKRLx9028094; Tue, 28 Nov 2023 12:27:21 -0800 Received: (from sr@localhost) by dragon.home.genyosha.net (8.14.7/8.14.7/Submit) id 3ASKRKQa028093; Tue, 28 Nov 2023 12:27:20 -0800 Date: Tue, 28 Nov 2023 12:27:20 -0800 From: Steve Rikli To: bob prohaska Cc: freebsd-arm Subject: Re: reboot hesitation on Pi3 running -current Message-ID: References: <4078F04C-B4AA-4029-B260-2A075A8832DA@yahoo.com> 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: X-Greylist: inspected by milter-greylist-4.6.4 (ns0.genyosha.net [50.39.243.220]); Tue, 28 Nov 2023 12:27:26 -0800 (PST) for IP:'50.39.243.219' DOMAIN:'ops0.genyosha.net' HELO:'dragon.home.genyosha.net' FROM:'sr@genyosha.net' RCPT:'' X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.4 (ns0.genyosha.net [50.39.243.220]); Tue, 28 Nov 2023 12:27:26 -0800 (PST) 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:20055, ipnet:50.39.128.0/17, country:US] X-Rspamd-Queue-Id: 4SfvC40Cz4z4dMt On Tue, Nov 28, 2023 at 12:00:08PM -0800, bob prohaska wrote: > On Tue, Nov 28, 2023 at 09:05:59AM -0800, Steve Rikli wrote: > > On Tue, Nov 28, 2023 at 08:15:30AM -0800, bob prohaska wrote: > > > On Tue, Nov 28, 2023 at 07:20:03AM -0800, Mark Millard wrote: > > > > On Nov 28, 2023, at 07:10, bob prohaska wrote: > > > > > > > > > A Pi3 running -current has taken to pausing during a shutdown > > > > > -r in a strange way: It gets to: > > > > > > > > > > Hit [Enter] to boot immediately, or any other key for command > > > > > prompt. Booting [/boot/kernel/kernel] in 5 second more > > > > > detailed help. > > > > > > > > > > It then stops at the OK prompt: > > > > > > > > > > OK boot <---typing boot fails: > > > > > > > > > > unknown command <---this looks strange, the kernel should > > > > > already be loaded > > > > > > > > A possibility here is garbage control characters, say before > > > > the "boot". YOu might want to type just to the first OK > > > > prompt and see if you ever still get "unknown command" once you > > > > do type just "boot" (and ). > > > > > > IIRC I've done that in the past with the same result, but memory > > > is hazy and an attempt at a second shutdown -r came back up > > > without hesitation. > > > > > > Another build/install cycle is running now, I'll be more careful > > > next time. > > > > > > > The fact that the countdown stopped at 5 (or other early value) > > > > suggests such extra text at that point. > > > > > > Rubbish on the serial console is a common occurence, but it usually > > > shows up when the USB end is taken down and brought back up. In this > > > case the USB end remained up throughout the reboot cycle, no stray > > > characters were visible. > > > > This topic has come up before here, I believe. > > > > I can confirm the same or very similar behavior on rpi4, and there's no > > USB-serial to disconnect on the remote end, rather an actual serial > > console server which is always-on. > > That's a significant (I think) observation. I couldn't tell where the > stray characters were originating and suspected the USB-serial > adapter. Your experience suggests very strongly the trouble is local > to the serial UART on the Pi or maybe wiring problems. I tend to agree. No USB-serial adapters involved in my setup. Wrt "wiring problem", fwiw I've tried multiple cables and db9 hoods, with both full-pins and 3-wire, no difference. All work as expected on other systems (NUC, various x86 PC, the occasional network gear etc.). > Is it possible that the serial port of the monitoring devices occasionally > echos output from the Pi's console back to the Pi? Seems to me it shouldn't, > but sometimes I see fragments of a login prompt among the rubbish. I imagine it's possible but I doubt it's happening. I've swapped ports on the serial console server as well JIC, again no change, and no other systems or devices exhibit behavior like this. > > Unfortunately it's not consistent behavior, i.e. sometimes the reboot > > proceeds uninterrupted. Sometimes typing 'boot' proceeds normally, > > sometimes typing 'boot' errors and then typing it again proceeds as > > normal. > > Does it sometimes reboot hands-off? Mine does, at least occasionally. Yes, sorry, that's what I meant by "sometimes reboot proceeds uninterrupted". > > I too have been thinking it's spurious chars on the serial console at > > various points, but I've yet to find a common behavior or consistent > > method to reproduce. This doesn't happen on my other serial consoles, > > FreeBSD or Linux. I also don't think it happened early on when this > > rpi4 was running raspbian for a brief time, but I didn't play with > > that setup very long. > > > > So far I believe it's avoidable by not watching the serial console > > during reboot, not necessary (I think) to disconnect the cable. But > > obviously that defeats the purpose of the serial console vs. a blind > > reboot. > > Hopefully "not watching" means disconnecting Rx and Tx from the GPIO > pins. If it means not looking at the display it's a whole 'nother story! > > 8-) Nothing is ever physically disconnected from the rpi4, if that's what you mean. Fyi my rpi4 serial console is via a "Serial Hat" which ultimately connects the appropriate GPIO pins to a db9 connector accessible outside the case, which is in-turn connected to my serial console server. "Not watching" in this context means I do not have an active connection to the serial console server port which communicates with the rpi4 db9 serial port. Somewhat analagous to not running tip/cu/minicom from your laptop or whatever system you use to connect to the rpi4 GPIO pins. Another note JIC: there are no keyboard, mouse, HDMI, or USB devices connected to any of the rpi4 ports. Only power, the serial console and a network cable. In that regard it is a neat little headless server, but unfortunately I don't really want to use it in production due to this issue. sr.