Re: Shutdown -r under -current hangs on RPi3

On Sep 23, 2023, at 15:26, bob prohaska <fbsd@www.zefox.net> wrote:

> On Sat, Sep 23, 2023 at 12:41:34PM -0700, Mark Millard wrote:
> [huge snip]
> 
>> 
>> So a "boot -v" before such sessions might, eventually, prove
>> useful.
>> 
> 
> Are you saying boot -v will affect or display extra shutdown
> messages?

Yes, such is possible. It even can cause extra messages
during normal operations. (Such is not its normal intent
but I've seen some normal-operation debug code guarded
by checking for verbose boot having been enabled.)

QUOTE
boot -v can add messages both to boot-time and to the
later reboot/shutdown-time.
END QUOTE

That does not mean that the boot -v is entered later
to do so.

However, there is:

# sysctl -Wd debug.bootverbose
debug.bootverbose: Control the output of verbose kernel messages

So use of:

# sysctl debug.bootverbose=1

before shutdown may be a way of controlling it later, after
having already booting. This might be handy if one forgot
to do the the boot -v at boot time.

> I couldn't find a man page for the boot command.

It is a FreeBSD-loader command, not a FreeBSD-OS command.
But the "-v" is interpreted by the kernel, not the loader.

There is:

# man loader_simp

but it just reports:

     boot
     boot kernelname [...]
     boot -flag ...
             Immediately proceeds to bootstrap the system, loading the kernel
             if necessary.  Any flags or arguments are passed to the kernel,
             but they must precede the kernel name, if a kernel name is
             provided.

It is the kernel that interprets the "-v", not the loader.

> Apologies if I'm being dense, but I don't see an opportunity
> to invoke boot -v manually after invoking shutdown -r.

That is because you do it before invoking shutdown -r .
You can not wait until the problem has already occurred.
You must cause the extra messaging to be enabled before
knowing if the problem will occur.

> Typically I type shutdown -r, the system may or may not
> emit the ertt message, but keeps going to emit the
> "Resetting system ..." message. At that time the system
> either reboots normally, or becomes unresponsive to the
> serial console. If it reboots, the red power LED turns
> on, the green LED flashes briefly, the disk LED starts
> flashing and the red LED turns off as boot progresses.
> 
> If the boot gets stuck the red LED remains off, given
> enough time the disk LED turns off. At that point power
> cycling seems to be the only way out. 
> 
> The fact that the system emits a "Resetting system"
> message suggests the complaint about ertt isn't fatal.

You assume, serial/sequential/single-threaded/non-interrupt
based. That may or may-not be the case. I'm giving
instructions based on covering both alternatives.

But I've also said that the extra messages are potentially
useful even if there is no ertt related message generated.
So it need not matter if the ertt related code is involved
in the hangup: boot -v ( or sysctl debug.bootverbose=1 )
is still appropriate.


===
Mark Millard
marklmi at yahoo.com