Re: RC2 seems to need kern.smp.disabled=1

On 11/26/18 4:49 PM, Mark Millard wrote:
> 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):
> 
>>
>> /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.

cool.

> 
> 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@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@eris:~ # openssl dgst -sha256 -r /usr/include/machine/vmparam.h
>> 023d840eb725d4310904cd3fd6560e23761c0e1141f38e354d73af2f126602ee */usr/include/machine/vmparam.h
>> root@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.)
>

Well I am just testing the off the shelf and out of the box bone stock
RC2 from the DVD.  That is all the "figure of speech" items I can think
of in one sentence right there :-)  Anyways RC1 was good and RC2 is not
good.  At least for smp stuff.

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

Oh heck .. I hate being the special data point.

I can boot the RC1 dvd and take a look. I may even just wipe the whole
disk and start over with a re-install of RC1.  Not sure what I can do
here to test but here is an idea :

0) boot with the RC1 dvd
1) I fetch a binary for my little gmp based factorial code thing
2) I fetch a gmp library shared object file also.
3) set LD_LIBRARY_PATH and run it ... should get four procs from sysconf
4) use RC2 and go back to (1)

Also I am still baffled about that double underscore BSD_VISIBLE thing.
However with __BSD_VISIBLE set I can get _SC_NPROCESSORS_CONF and also
the current _SC_NPROCESSORS_ONLN.  Not sure yet how to offline a cpu in
FreeBSD but that is a whole other question for some other day.

> (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.)

Well I think I had best get on with a kernel build here or go back to
RC1 or some other way to figure this out.  Building a kernel seems like
more fun but the make.conf has me baffled :

https://www.freebsd.org/cgi/man.cgi?query=make.conf&sektion=5&manpath=freebsd-release-ports

Right.  I have three of those.

root@eris:~ # find / -type f -name make.conf -ls | sed -e 's/ 
                 //g'
20627255       24 -r--r--r--    1 root wheel   10736 Nov 23 20:26 
/usr/share/examples/etc/make.conf
20711864       24 -rw-r--r--    1 root wheel   10736 Nov 23 16:34 
/usr/src/share/examples/etc/make.conf
47511975        8 -rw-r--r--    1 root wheel      29 Nov 26 21:11 
/etc/make.conf
root@eris:~ #

This should be fun.

Dennis
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
To unsubscribe, send any mail to "[email protected]"