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>