Fwd: Old PowerMac G5 2-socket/2-cores-each: head -r368820 kernel reports: bus_dmamem_alloc failed to align memory properly

-------- 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 <[email protected]>
To: 	Mark Millard <[email protected]>



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)
>
> _______________________________________________
> [email protected] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
> To unsubscribe, send any mail to "[email protected]"

_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
To unsubscribe, send any mail to "[email protected]"