Date: Tue, 28 Nov 2023 12:47:53 -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: <9E47467E-4147-4E08-899A-94D59A1A75F6@yahoo.com> In-Reply-To: <301571AE-130B-4BF7-B703-9458CF524F46@yahoo.com> 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> <301571AE-130B-4BF7-B703-9458CF524F46@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 28, 2023, at 12:35, Mark Millard <marklmi@yahoo.com> wrote: > On Nov 28, 2023, at 12:27, Steve Rikli <sr@genyosha.net> wrote: >=20 >> 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. >=20 > 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. >=20 I found some of the old text that referenced one of the examples of a U-Boot -> Loader text oddity. Here it the 2023-mid-April text: QUOTE But I can report that the prior <ESC>[6n (Query Cursor Position) before the FreeBSD loader's OK prompt is during U-Boot activity: part of the escpe sequences just after: Device 0: Vendor: OWC Rev: 0 Prod: Envoy Pro mini =20 Type: Hard Disk Capacity: 228936.5 MB =3D 223.5 GB (468862128 x 512) ... is now current device Scanning usb 0:1... This suggests that U-Boot failed to read/clear some of the Report Cursor Position text --and that the loader accepts what it finds already present (probably so that typing ahead of time would work). So: Looks to me like a probable U-Boot issue for which a FreeBSD workaround to ignore text would have other consequences (lack of effective typeahead for the loader prompt). END QUOTE =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?9E47467E-4147-4E08-899A-94D59A1A75F6>