PoerMac G5 "4 core" (system total): some from-power-off booting observations of the modern VM_MAX_KERNEL_ADDRESS value mixed with usefdt=1

[Mark Millard]

[Where boot -v output is different between booting to completion vs.
hanging up: actual text.]

On 2019-Jan-29, at 17:52, Mark Millard <marklmi at yahoo.com> wrote:

> For the modern VM_MAX_KERNEL_ADDRESS value and also use of the usefdt=1 case:
> 
> This usually hang during boot during the "Waking up CPU" message sequence.
> 
> But not always. Powering off and retrying , sometimes just a few times, and
> other times dozens of times, the system that I have access to does eventually
> boot for the combination. So some sort of race condition or lack of stable
> initialization?
> 
> When it does boot, smp seems to be set up and working.
> 
> Once booted, it is usually not very long until the fans are going wild,
> other than an occasional, temporary lull.
> 
> 
> 
> For for shutting down the following applies to both VM_MAX_KERNEL_ADDRESS
> values when a usefdt=1 type of context is in use:
> 
> When I've kept explicit track, I've not had any example of all of the:
> 
> Waiting (max 60 seconds) for system thread `bufdaemon' to stop...
> Waiting (max 60 seconds) for system thread `bufspacedaemon-1' to stop...
> Waiting (max 60 seconds) for system thread `bufspacedaemon-0' to stop...
> . . .
> 
> getting to "done": instead one or more time out. Which and how many
> vary.
> 
> The fans tend to take off for both VM_MAX_KERNEL_ADDRESS values. The
> buf*daemon timeouts happen even if the fans have not taken off.
> 

With VM_MAX_KERNEL_ADDRESS reverted or a successful
boot with the modern value:

Adding CPU 0, hwref=cd38, awake=1
Waking up CPU 3 (dev=c480)
Adding CPU 3, hwref=c480, awake=1
Waking up CPU 2 (dev=c768)
Adding CPU 2, hwref=c768, awake=1
Waking up CPU 1 (dev=ca50)
Adding CPU 1, hwref=ca50, awake=1
SMP: AP CPU #3 launched
SMP: AP CPU #2 launched
SMP: AP CPU #1 launched
Trying to mount root from ufs:/dev/ufs/FBSDG5L2rootfs [rw,noatime]...


With the modern VM_MAX_KERNEL_ADDRESS value for a boot attempt
that failed, an example (typed from a picture of the screen) is:

Adding CPU 0, hwref=cd38, awake=1
Waking up CPU 3 (dev=c480)

Another is:

Adding CPU 0, hwref=cd38, awake=1
Waking up CPU 3 (dev=c480)
Waking up CPU 2 (dev=c768)

(Both examples have no more output.)

So CPUs 1..3 do not get "Adding CPU" messages. Also:
I do not remember seeing all 3 "Waking up CPU" messages,
just 1 or 2 of them.

(Sometimes the "Trying to mount root from" message is in
the mix as I remember.)


One point of difference that is consistently observable for
the old vs. modern VM_MAX_KERNEL_ADDRESS values is how many
bufspacedaemon-* threads there are:

old VM_MAX_KERNEL_ADDRESS value: 0..2
new VM_MAX_KERNEL_ADDRESS value: 0..6


I have had many boot attempts in a row boot
for the modern VM_MAX_KERNEL_ADDRESS value,
though not as many as the dozens of failures
in a row. Highly variable with lots of
testing.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)