Date: Tue, 28 Nov 2023 12:35:34 -0800 From: Mark Millard <marklmi@yahoo.com> To: Steve Rikli <sr@genyosha.net>, bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: reboot hesitation on Pi3 running -current Message-ID: <301571AE-130B-4BF7-B703-9458CF524F46@yahoo.com> In-Reply-To: <ZWZNKECfMEktSphI@dragon.home.genyosha.net> References: <ZWYCygMbVO9jFrWH@www.zefox.net> <4078F04C-B4AA-4029-B260-2A075A8832DA@yahoo.com> <ZWYSIlPorvAMVQQT@www.zefox.net> <ZWYd9zRl4F5OfyhC@dragon.home.genyosha.net> <ZWZGyB/yfNHNHhhv@www.zefox.net> <ZWZNKECfMEktSphI@dragon.home.genyosha.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 28, 2023, at 12:27, Steve Rikli <sr@genyosha.net> wrote: > 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 <fbsd@www.zefox.net> = wrote: >>>>>=20 >>>>>> A Pi3 running -current has taken to pausing during a shutdown >>>>>> -r in a strange way: It gets to:=20 >>>>>>=20 >>>>>> Hit [Enter] to boot immediately, or any other key for command >>>>>> prompt. Booting [/boot/kernel/kernel] in 5 second more >>>>>> detailed help. >>>>>>=20 >>>>>> It then stops at the OK prompt: >>>>>>=20 >>>>>> OK boot <---typing boot fails: >>>>>>=20 >>>>>> unknown command <---this looks strange, the kernel should >>>>>> already be loaded >>>>>=20 >>>>> A possibility here is garbage control characters, say before >>>>> the "boot". YOu might want to type just <return> to the first OK >>>>> prompt and see if you ever still get "unknown command" once you >>>>> do type just "boot" (and <return>). >>>>=20 >>>> 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. >>>>=20 >>>> Another build/install cycle is running now, I'll be more careful >>>> next time. >>>>=20 >>>>> The fact that the countdown stopped at 5 (or other early value) >>>>> suggests such extra text at that point. >>>>=20 >>>> 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=20= >>>> characters were visible. >>>=20 >>> This topic has come up before here, I believe. >>>=20 >>> 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. >>=20 >> 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.=20 >=20 > 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.). >=20 >> 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.=20 >=20 > 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. >=20 >>> 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. >>=20 >> Does it sometimes reboot hands-off? Mine does, at least occasionally. >=20 > Yes, sorry, that's what I meant by "sometimes reboot proceeds = uninterrupted". >=20 >>> 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. >>>=20 >>> 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. >>=20 >> 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! >>=20 >> 8-) >=20 > 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. >=20 > "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. >=20 > Somewhat analagous to not running tip/cu/minicom from your laptop or > whatever system you use to connect to the rpi4 GPIO pins. >=20 > 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. I'm going to remind of the known issue with U-Boot on the RPi*'s sometimes leading to odd serial connection behavior for the transition from U-Boot based UEFI handling the serial connection to the FreeBSD UEFI loader handling it. =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?301571AE-130B-4BF7-B703-9458CF524F46>