RC2 seems to need kern.smp.disabled=1

[Mark Millard]

On 2018-Nov-26, at 13:07, Dennis Clarke <dclarke at blastwave.org> wrote:

On 11/26/18 2:41 PM, Mark Millard wrote:
> On 2018-Nov-26, at 11:13, Dennis Clarke <dclarke at blastwave.org> wrote:
>> Hello ppc64 types:
>> 
>> Merely an observation that RC1 was running more or less fine without the
>> need to castrate the smp feature whereas RC2 won't even boot.
> If you were able to smp boot a PowerMac G5 based on a version that
> was based on:
> #define VM_MAX_KERNEL_ADDRESS           0xe0000007ffffffffUL
> from sys/powerpc/include/vmparam.h that is interesting.
> This is the value I (and others?) have been reverting to:
> #define VM_MAX_KERNEL_ADDRESS           0xe0000001c7ffffffUL
> in order to allow smp use on such G5's. Quoting an old reply
> from 2018-Oct-11 (-r??????'s are from 13-CURRENT):

> I don't see that file in my install but then again I did not drag in the sources or much of anything to get off the ground.  What I do have is :
> 
> /usr/include/machine/vmparam.h

The build targeting powerpc64 produces /usr/include/machine/vmparam.h by
copying /usr/src/sys/powerpc/include/vmparam.h . If the matching /src/src/
is not present, then /usr/include/machine/vmparam.h is the right place to
look.

But to change the build it is /usr/src/sys/powerpc/include/vmparam.h that
should change before the build. (Which is why I referenced that sort of
path.)

> which says :
> 
> #define VM_MAX_KERNEL_ADDRESS           0xe0000007ffffffffUL
> 
> Looking into https://download.freebsd.org/ftp/releases/powerpc/powerpc64/12.0-RC2/src.txz I see :
> 
> 
> root at eris:~ # grep "VM_MAX_KERNEL_ADDRESS" /usr/src/sys/powerpc/include/vmparam.h
> #define VM_MAX_KERNEL_ADDRESS           0xe0000007ffffffffUL
> #define VM_MAX_SAFE_KERNEL_ADDRESS      VM_MAX_KERNEL_ADDRESS
> #define VM_MAX_KERNEL_ADDRESS   (VM_MIN_KERNEL_ADDRESS + 3*SEGMENT_LENGTH - 1)
> #define VM_MAX_KERNEL_ADDRESS   0xffffefff
> #define VM_MAX_SAFE_KERNEL_ADDRESS      VM_MAX_KERNEL_ADDRESS
> 
> I certainly didn't change anything :
> 
> root at eris:~ # openssl dgst -sha256 -r /usr/include/machine/vmparam.h
> 023d840eb725d4310904cd3fd6560e23761c0e1141f38e354d73af2f126602ee */usr/include/machine/vmparam.h
> root at eris:~ # openssl dgst -sha256 -r /usr/src/sys/powerpc/include/vmparam.h
> 023d840eb725d4310904cd3fd6560e23761c0e1141f38e354d73af2f126602ee */usr/src/sys/powerpc/include/vmparam.h

I did not intend to suggest that you had. I intended to indicate
that that new value has been observed to expose problems by
me and others. I reverted to the value from before Justin H.'s
change and some other folks may have as well. (I do my own
builds. I started using the reverted value during 12 before I
progressed to 13 and I'm still using the reverted value.)

> 
> In any case maybe I am wrong in some way and should try a boot
> without setting kern.smp.disabled and see what happens.
> 
> Nope.
> 
> Machine will not boot.
> 
> So the exact same hardware will boot and run fine with RC1 but not with
> RC2. That is certain.  Unless kern.smp.disabled=1 is set.

RC1 is also based on 0xe0000007ffffffffUL so this is interesting.
But I've no clue how to analyze the distinction at this point.
Justin H. or Nathan W. or someone else might some up with some way
to get some information from the two contexts that might point at
something. You may have the only observed-good smp G5-boot based
on code that used the 0xe0000007ffffffffUL value.

(It may well be that 0xe0000007ffffffffUL should be valid and some
other issue is involved that the older, smaller value happens to
avoid in more contexts. My reverting the value is a hack at this
point, not a know-good long-term solution. But the problem the new
value exposes would then likely be older than the value increase.)

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