Date: Sat, 13 Oct 2018 12:18:15 -0700 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: 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: <00fd0879-f071-380e-dc05-0d206bca3c65@freebsd.org> In-Reply-To: <68d24bdd-9542-3007-3deb-271dcb722e9e@fgznet.ch> 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> <4fe5af91-bbef-7873-3c48-4b1b440c871a@fgznet.ch> <68d24bdd-9542-3007-3deb-271dcb722e9e@fgznet.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/9/18 2:07 PM, Andreas Tobler wrote: > On 09.10.18 22:40, Andreas Tobler wrote: >> On 09.10.18 22:35, Mark Millard via freebsd-ppc wrote: >>> [Reverting head -r334498 in my head -r339076 context was enough to ge= t >>> the G5 so-called "Quad Core" to boot just fine as a variant of >>> -r339076 .] >>> >>> On 2018-Oct-9, at 12:54 PM, Mark Millard <marklmi at yahoo.com> wrote= : >>> >>>> On 2018-Oct-9, at 8:20 AM, Mark Millard <marklmi at yahoo.com> wrote= : >>>> >>>>> [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".] >>>>> >>>>> On 2018-Oct-8, at 5:14 PM, Mark Millard <marklmi at yahoo.com> wrot= e: >>>>> >>>>>> On 2018-Oct-8, at 1:27 PM, Justin Hibbits <chmeeedalf at >>>>>> gmail.com> wrote: >>>>>> >>>>>>>> . . . >>>>>>> >>>>>>> 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.=C2=A0 Since my = G5 >>>>>>> bit the >>>>>>> dust, I can't check locally. >>>>>> >>>>> . . . >>>> >>>> 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: >>>> >>>> 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.) >>>> >>>> My reporting "worked" for a revision might be a >>>> misclassification. (This makes for a messier >>>> "binary-like search".) >>>> >>>> That said, the summary of the later detail is: >>>> >>>> head -r334494 kernel worked >>>> head -r334528 kernel failed >>>> >>>> (There is nothing between those for: >>>> >>>> https://artifact.ci.freebsd.org/snapshot/head/r*/powerpc/powerpc64/k= ernel.txz >>>> >>>> >>>> so getting a smaller range requires builds. >>>> I've not attempted that.) >>>> >>>> The only machine-dependent powerpc64 change between >>>> those 2 that I see is: >>>> >>>> Author: jhibbits >>>> Date: Fri Jun=C2=A0 1 21:37:20 2018 >>>> New Revision: 334498 >>>> URL: >>>> https://svnweb.freebsd.org/changeset/base/334498 >>>> >>>> >>>> Log: >>>> =C2=A0=C2=A0 Increase powerpc64 KVA from ~7.25GB to 32GB >>>> . . . >>>> >>>> . . . >>> >>> In my -r339076 build context I reverted -r334498, did a >>> buildkernel, installed it, and rebooted into -r339076. >>> >>> The result booted just fine. >>> >>> It does appear that, for head, -r334498 makes the difference >>> for some reason. >> >> Unfortunately I have to confirm your findings. > > Mark, how much physical ram do you have? Can you adjust the > VM_MAX_KERNEL_ADDRESS just below the amount of RAM you have and see if > -CURRENT boots? Here it does, I have 14GB and I adjusted > VM_MAX_KERNEL_ADDRESS to 12GB. It is just a trial to find out what is > happening. > > Thanks, > Andreas My guess is that the combination of large RAM (so big DMAP) and large KVA is causing SLB overflows: a combination of these above 16 GB will make this rate non-zero. These are fine while in the kernel or userspace -- they get handled transparently -- but could be fatal during a call to Open Firmware, which, on Apple hardware, operates with the MMU on since OF doesn't have the appropriate trap handlers to handle DSE/ISE. This would also explain why the issue only affects Apple hardware. There would be a few ways to fix it: 1. Distill the OF tree to an FDT before starting the kernel (usefdt=3D1 option in the loader). There are still issues with this on some Apple hardware. 2. Right before calling into OF, and after any possibility of=C2=A0 prefa= ult all the possible SLB entries corresponding to any 32-bit address (all the ones OF could possibly use) to eliminate the possibility of in-firmware SLB faults. 3. Leave the kernel SLB fault handlers (+ associated metadata at low addresses) in place during OF calls. -Nathan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?00fd0879-f071-380e-dc05-0d206bca3c65>