Re: reboot hesitation on Pi3 running -current
- Reply: Mark Millard : "Re: reboot hesitation on Pi3 running -current"
- In reply to: Steve Rikli : "Re: reboot hesitation on Pi3 running -current"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Tue, 28 Nov 2023 20:35:34 UTC
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: >>>>> >>>>>> 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 <return> to the first OK >>>>> prompt and see if you ever still get "unknown command" once you >>>>> do type just "boot" (and <return>). >>>> >>>> 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. 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. === Mark Millard marklmi at yahoo.com