Date: Tue, 22 Dec 2020 01:09:11 -0800 From: Mark Millard <marklmi@yahoo.com> To: Brandon Bergren <bdragon@FreeBSD.org> Cc: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: Old PowerMac G5 2-socket/2-cores-each: head -r368820 kernel reports: bus_dmamem_alloc failed to align memory properly Message-ID: <7870C7CB-6104-4A63-AA86-4981913FA48D@yahoo.com> In-Reply-To: <66ce8494-204b-4b8b-a043-94ba00509f41@www.fastmail.com> References: <FE22D733-35A2-4FB4-83D7-1E953A53AC34.ref@yahoo.com> <FE22D733-35A2-4FB4-83D7-1E953A53AC34@yahoo.com> <40dead6f-2a69-cf74-0a23-cde56dd90510@blastwave.org> <53f15d43-62c3-e12c-f8db-ede6a30e4e95@blastwave.org> <46726BE0-00FF-4DE7-835B-C7B04F3B0693@yahoo.com> <04727338-1ecb-4a94-c8e9-dcef7abd1513@blastwave.org> <66ce8494-204b-4b8b-a043-94ba00509f41@www.fastmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Dec-21, at 21:11, Brandon Bergren <bdragon at FreeBSD.org> = wrote: > On Mon, Dec 21, 2020, at 10:25 PM, Dennis Clarke via freebsd-ppc = wrote: >> On 12/21/20 11:03 PM, Mark Millard wrote: >>=20 >>> As far as I know, 32-bit powerpc for old PowerMacs still has the = kernel >>> gradually zeroing out user-space pages, even for = single-socket/single-core >>> 32-bit PowerMacs. So I run 32-bit via a chroot on a 64-bit system: = the >>> 64-bit kernel does not have this specific problem. (I seem to = remember >>> that there was a different boot failure last I tried 32-bit, but I = do not >>> remember any detail at this time.) >=20 > This is the bridge mode bug that we haven't figured out yet. It's = specific to the G5 running a 32 bit kernel. The problem doesn't manifest = on actual 32-bit MMUs. I combined more than one thing in that paragraph, making things hard to follow in the reply. I'll provide reminders of context for both things. Neither matches with a G5 being in use. For the "seem to remember" part of my text . . . Wrong problem and wrong machine context, I'm afraid. Back on Sept-22 I reported for the 2-socket G4s (typos preserved): Subject: head -r365932 for 320bit powerpc unable to boot 2-socket = PowerMac G4 QUOTE I attempted to boot an update from head -r365590 to head -r365932 and it dies just after: Kernel entry at 0x100620 via: Invalid memory access at %SRR0: 0000ffff %SRR1: 00ffffff END QUOTE (I did report at the time that the G5 gets much further along than the above when that same media (and content) is used to try to boot the G5. But the report was about the G4 context.) As for the "gradually zeroing out user-space pages" . . . For this I was referencing there being no G3/G4 code analogous to the 64 bit code clearing of PGA_EXECUTABLE (and possibly other issues too), nothing like the: vm_page_aflag_clear(????,PGA_WRITEABLE | PGA_EXECUTABLE) in the 64 bit code. I've demonstrated and reported the problem that results on each of: A) A G3 PowerMac (the only one I have access to) B) A single-socket/single thread G4 PowerMac C) Two 2-Socket G4 PowerMacs (but of the same type, the only such type that I've access to) Justin took a couple of stabs at fixing the problem before the specifics of clearing PGA_EXECUTABLE needing to be part of a working fix was identified. (My statements of the history may be over simplified but I think generally point in the right direction.) The sequence of messages about the kernel bug(s) ended with: https://lists.freebsd.org/pipermail/freebsd-ppc/2020-June/011916.html https://lists.freebsd.org/pipermail/freebsd-ppc/2020-June/011917.html https://lists.freebsd.org/pipermail/freebsd-ppc/2020-June/011969.html https://lists.freebsd.org/pipermail/freebsd-ppc/2020-June/011970.html https://lists.freebsd.org/pipermail/freebsd-ppc/2020-June/011971.html Even booting and leaving such a machine idle eventually has processes die from the zeroed pages (not quickly). It is easier/quicker to see the problem by building with a debug jemalloc (no MALLOC_PRODUCTION=3D in use): the debug code notices problems with jemalloc's own memory being zeroed much earlier generally, still not quickly when idle. I've not noticed anything go by that involved clearing PGA_EXECUTABLE so I expect that things are still broken. Note: There were other notes about potential kernel code issues but I'm not going to relist everything that looked like it might be an issue of some kind. I had traced PGA_EXECUTABLE mis-handling to be a definite problem. =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?7870C7CB-6104-4A63-AA86-4981913FA48D>