Date: Mon, 26 Nov 2018 13:49:27 -0800 From: Mark Millard <marklmi@yahoo.com> To: Dennis Clarke <dclarke@blastwave.org> Cc: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: RC2 seems to need kern.smp.disabled=1 Message-ID: <FB9372B1-A0D5-463B-803F-C63B8F43385B@yahoo.com> In-Reply-To: <edb8d3c4-dab5-6d3e-fcec-69c9accf93cd@blastwave.org> References: <57efdab7-568c-623e-4b66-cf5ed7c138bf@blastwave.org> <179CF982-D123-483D-B3B9-188010C39BD5@yahoo.com> <edb8d3c4-dab5-6d3e-fcec-69c9accf93cd@blastwave.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >>=20 >> 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 : >=20 > /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 : >=20 > #define VM_MAX_KERNEL_ADDRESS 0xe0000007ffffffffUL >=20 > Looking into = https://download.freebsd.org/ftp/releases/powerpc/powerpc64/12.0-RC2/src.t= xz I see : >=20 >=20 > 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 >=20 > I certainly didn't change anything : >=20 > 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.) >=20 > In any case maybe I am wrong in some way and should try a boot > without setting kern.smp.disabled and see what happens. >=20 > Nope. >=20 > Machine will not boot. >=20 > So the exact same hardware will boot and run fine with RC1 but not = with > RC2. That is certain. Unless kern.smp.disabled=3D1 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.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FB9372B1-A0D5-463B-803F-C63B8F43385B>