Date: Tue, 22 Dec 2020 09:37:55 +0000 From: Javi Hotmail <volkovdablo@hotmail.com> To: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Fwd: Old PowerMac G5 2-socket/2-cores-each: head -r368820 kernel reports: bus_dmamem_alloc failed to align memory properly Message-ID: <DB8PR04MB686056BC8F9A4DDBF015122BACDF0@DB8PR04MB6860.eurprd04.prod.outlook.com> In-Reply-To: <DB8PR04MB68606AB87A6237B05A402EF3ACDF0@DB8PR04MB6860.eurprd04.prod.outlook.com> References: <DB8PR04MB68606AB87A6237B05A402EF3ACDF0@DB8PR04MB6860.eurprd04.prod.outlook.com>
next in thread | previous in thread | raw e-mail | index | archive | help
-------- Forwarded Message -------- Subject: Re: Old PowerMac G5 2-socket/2-cores-each: head -r368820 kernel reports: bus_dmamem_alloc failed to align memory properly Date: Tue, 22 Dec 2020 09:36:45 +0000 From: Javi Hotmail <volkovdablo@hotmail.com> To: Mark Millard <marklmi@yahoo.com> One thing that would really help is having the possibility to hook a JTAG. I've been trying to get my head around doing that for my G5, but it seems that there is not a lot of information in this regard. Also getting something like a RiscWatch seems close to impossible. To me that is the main issue with this device (or with any device that I try to debug for that matter). Being blind on the kernel side or doing printk and stuff is such a big deterrent for me to jump and fix this issues in the first place. If anybody knows anything in this regard please comment, I really would like to get my Xserve to work without a dozen patches and workarounds. Javi. On 22/12/2020 09:09, Mark Millard via freebsd-ppc wrote: > 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: >>> >>>> 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.) >> 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= 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. > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DB8PR04MB686056BC8F9A4DDBF015122BACDF0>