Date: Tue, 9 Oct 2018 14:28:45 -0700 From: Mark Millard <marklmi@yahoo.com> To: Michael Tuexen <tuexen@fh-muenster.de> Cc: Justin Hibbits <chmeeedalf@gmail.com>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: Failed attempt to boot a (non-debug) head -r339076 on an old PowerMac G5 "Quad Core" (built via devel/powerpc64-gcc): Waking up CPU 1 Message-ID: <4E2CE5AF-BBE7-4C60-A983-3B0F8B3AAA21@yahoo.com> In-Reply-To: <937E631B-929D-4F2B-8AA2-A7D1154EADFD@fh-muenster.de> References: <0E6DB192-37A3-45EC-87E9-C5AA1C9397AE@yahoo.com> <785D268A-2612-459F-BD1F-A650D9ECCA28@fh-muenster.de> <A62CE721-B12A-4A79-BC43-F4E0F412D695@yahoo.com> <A7E94F86-E160-4E58-8C44-99DE109D2758@fh-muenster.de> <3DCB6910-6F08-408A-B3D1-70A7EB5A55BC@yahoo.com> <037e3dd6-cc0c-a39f-f074-bce01887156c@blastwave.org> <20181008152746.1aba4221@ralga.knownspace> <AF5D435D-727A-4C8B-8E9C-749CDB1E2140@yahoo.com> <031407DB-57AD-4E09-9A22-A0D4A347576E@yahoo.com> <C0FD8A95-A3DA-45FA-A59E-C7308EA95DFF@yahoo.com> <C6D71821-60D9-41E4-810B-008CDA772A80@yahoo.com> <937E631B-929D-4F2B-8AA2-A7D1154EADFD@fh-muenster.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2018-Oct-9, at 1:40 PM, Michael Tuexen <tuexen at fh-muenster.de> = wrote: >> On 9. Oct 2018, at 22:35, Mark Millard <marklmi at yahoo.com> wrote: >>=20 >> [Reverting head -r334498 in my head -r339076 context was enough to = get >> the G5 so-called "Quad Core" to boot just fine as a variant of >> -r339076 .] >>=20 >> On 2018-Oct-9, at 12:54 PM, Mark Millard <marklmi at yahoo.com> = wrote: >>=20 >>> On 2018-Oct-9, at 8:20 AM, Mark Millard <marklmi at yahoo.com> = wrote: >>>=20 >>>> [The stable/head mix seems to be a wrong idea: 11.2 gets past >>>> the SMP: messages just fine on the so-called G5 "Quad Core".] >>>>=20 >>>> On 2018-Oct-8, at 5:14 PM, Mark Millard <marklmi at yahoo.com> = wrote: >>>>=20 >>>>> On 2018-Oct-8, at 1:27 PM, Justin Hibbits <chmeeedalf at = gmail.com> wrote: >>>>>=20 >>>>>>> . . . >>>>>>=20 >>>>>> It would be helpful to know the last known-good SVN revision, = both for >>>>>> Head and 11.x, as well as the oldest failing one. Since my G5 = bit the >>>>>> dust, I can't check locally. >>>>>=20 >>>> . . . >>>=20 >>> There are examples of head's kernels that sometimes >>> fail to get to the "SMP:" messages and sometimes work >>> for getting there (and beyond). So: >>>=20 >>> My reporting any example failure is a solid indicator >>> of the "does not reach "SMP:" problem in that build. >>> (All tries reached the waking message on at least cpu >>> 1.) >>>=20 >>> My reporting "worked" for a revision might be a >>> misclassification. (This makes for a messier >>> "binary-like search".) >>>=20 >>> That said, the summary of the later detail is: >>>=20 >>> head -r334494 kernel worked >>> head -r334528 kernel failed >>>=20 >>> (There is nothing between those for: >>>=20 >>> = https://artifact.ci.freebsd.org/snapshot/head/r*/powerpc/powerpc64/kernel.= txz >>>=20 >>> so getting a smaller range requires builds. >>> I've not attempted that.) >>>=20 >>> The only machine-dependent powerpc64 change between >>> those 2 that I see is: >>>=20 >>> Author: jhibbits >>> Date: Fri Jun 1 21:37:20 2018 >>> New Revision: 334498 >>> URL:=20 >>> https://svnweb.freebsd.org/changeset/base/334498 >>>=20 >>>=20 >>> Log: >>> Increase powerpc64 KVA from ~7.25GB to 32GB >>> . . . >>>=20 >>> . . . >>=20 >> In my -r339076 build context I reverted -r334498, did a >> buildkernel, installed it, and rebooted into -r339076. >>=20 >> The result booted just fine. >>=20 >> It does appear that, for head, -r334498 makes the difference >> for some reason. > Are you saying that head with reverting r334498 runs stable with SMP? >=20 So far no problems. I'll later be doing more extensive activity, such as buildworld buildkernel and poudriere-based port builds. So the quality of evidence will improve and I'll report on how it went. BUT: I'm running a build based on devel/powerpc64-gcc having done the buildworld buildkernel (WITHOUT_LIB32=3D specified). It was an amd64->powerpc64 cross-build as well. No gcc 4.2.1 in use or present. The powerpc64 build has clang as cc (even though clang messes up buildworld buildkernel if used). So, it is not a match to an official build. For reference, my experimental status has some other /usr/src differences from head -r339076 as well: # svnlite status /usr/src/ | sort ? /usr/src/sys/amd64/conf/GENERIC-DBG ? /usr/src/sys/amd64/conf/GENERIC-NODBG ? /usr/src/sys/arm/conf/GENERIC-DBG ? /usr/src/sys/arm/conf/GENERIC-NODBG ? /usr/src/sys/arm64/conf/GENERIC-DBG ? /usr/src/sys/arm64/conf/GENERIC-NODBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG M /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp M /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp M /usr/src/crypto/openssl/crypto/armcap.c M /usr/src/lib/libkvm/kvm_powerpc.c M /usr/src/lib/libkvm/kvm_private.c M /usr/src/release/Makefile.vm M /usr/src/release/scripts/mk-vmimage.sh M /usr/src/release/tools/vmimage.subr M /usr/src/secure/lib/libcrypto/Makefile M /usr/src/stand/defs.mk M /usr/src/stand/powerpc/boot1.chrp/Makefile M /usr/src/stand/powerpc/kboot/Makefile M /usr/src/sys/arm/allwinner/aw_mmc.c M /usr/src/sys/arm64/arm64/identcpu.c M /usr/src/sys/conf/kmod.mk M /usr/src/sys/conf/ldscript.powerpc M /usr/src/sys/ddb/db_main.c M /usr/src/sys/ddb/db_script.c M /usr/src/sys/dev/mmc/mmc.c M /usr/src/sys/dev/mmc/mmcreg.h M /usr/src/sys/dev/mmc/mmcsd.c M /usr/src/sys/kern/subr_pcpu.c M /usr/src/sys/powerpc/aim/mmu_oea64.c M /usr/src/sys/powerpc/include/vmparam.h M /usr/src/sys/powerpc/ofw/ofw_machdep.c M /usr/src/sys/powerpc/powerpc/interrupt.c M /usr/src/sys/powerpc/powerpc/mp_machdep.c M /usr/src/sys/powerpc/powerpc/trap.c M /usr/src/sys/sys/buf.h M /usr/src/sys/vm/swap_pager.c M /usr/src/sys/vm/vm_page.c M /usr/src/sys/vm/vm_pageout.c M /usr/src/usr.bin/top/machine.c Some of this is for 32-bit powerpc, some for powerpc64, some for aarch64, some for armv7. A few files just have extra validation/diagnostic code from when a problem was being investigated. The GENERIC*-DBG and GENERIC*-NODBG files include the matching GENERIC* and then modify some debug-status definitions. For powerpc and powerpc64 they also build in: device filemon device geom_label (This is tied to doing experiments with problematical clang based buildworld buildkernel results where kld_load crashes the system.) =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?4E2CE5AF-BBE7-4C60-A983-3B0F8B3AAA21>