Date: Mon, 26 Nov 2018 17:36:42 -0500 From: Dennis Clarke <dclarke@blastwave.org> To: Mark Millard <marklmi@yahoo.com> Cc: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: RC2 seems to need kern.smp.disabled=1 Message-ID: <22917196-317d-e559-f18c-bc4c6c9293da@blastwave.org> In-Reply-To: <FB9372B1-A0D5-463B-803F-C63B8F43385B@yahoo.com> References: <57efdab7-568c-623e-4b66-cf5ed7c138bf@blastwave.org> <179CF982-D123-483D-B3B9-188010C39BD5@yahoo.com> <edb8d3c4-dab5-6d3e-fcec-69c9accf93cd@blastwave.org> <FB9372B1-A0D5-463B-803F-C63B8F43385B@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?22917196-317d-e559-f18c-bc4c6c9293da>