Re: reboot hesitation on Pi3 running -current

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:
> 
>> 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.
> 

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  
           Type: Hard Disk
           Capacity: 228936.5 MB = 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

===
Mark Millard
marklmi at yahoo.com