head -r365932 on PowerMac G5 (2 dual-core sockets): Crashes before login prompt if powerd is enabled in /etc/rc.conf

[Mark Millard]

On 2020-Sep-23, at 15:31, Brandon Bergren <bdragon at FreeBSD.org> wrote:

> On Wed, Sep 23, 2020, at 5:10 PM, Mark Millard wrote:
>> In my enviroment, doing:
>> 
>> gpart bootcode -p /boot/boot1.hfs -i1 ada1
>> 
>> from a modern, booting context got the failing
>> SSD to boot single-socket, single-core PowerMacs.
>> 
>> Thanks!
>> 
>> It changed the behavior of 2-socket G4 as well but
>> that context now reports starting only one of the 2
>> CPUs and things do not go well from there. For
>> example, USB2 fails and it basically hangs up before
>> the login prompt (but it does check the root file
>> system). It even reported something about NUMA
>> domain 0 in the messages that I saw go by.
> 
> Yes, for me on my 2-socket G4, it gets as far as mounting the root filesystem and starting filesystem checks before it hangs. I still need to set up dcons there and poke around a bit.

Sounds like I've probably caught up with your status,
intead of being behind.

>> Before, 2-socket died much earlier. But it is not
>> getting to a status where I have any control/access.
>> 
>> Of course, so far as I know, nothing has fixed the
>> "kernel sometimes zeros user space pages that it
>> should not" problem (even when sitting idle). So,
>> ultimately, 32-bit powerpc FreeBSD is not sufficiently
>> useful on any of the machines, other than via chroot
>> on a powerpc64 FreeBSD machine.
> 
> I do know there is a bug somewhere in bridge mode that corrupts things when running 32 bit on a G5 processor, but G3 and G4 should still be working fine...

This is the old issue where Justin H. had written:

QUOTE
. . . I took a quick look at the 3 pmap
implementations we have (haven't check the new radix pmap yet), and it
looks like only mmu_oea.c (32-bit AIM pmap, for G3 and G4) is missing
vm_page_dirty() calls in its pmap_protect() implementation,. . .
Given this, I think it's safe to
say that this missing piece is necessary.  . . .
END QUOTE

The attempted patches did not work back then (June).

You later wrote:

QUOTE
looking at the history of the 64 bit code:
r233017 -- "Implement pmap_remove_pages(). This will be added later to the 32-bit MMU module."

Oops!
END QUOTE

My last note on teh subject (my reply to the above) looks to be:

QUOTE
Looks like -r233949 is the first version of mmu_oea64.c
to involve clearing PGA_EXECUTABLE from the a.flags .
Later versions changed various aspects over the years
but clearing PGA_EXECUTABLE and PGA_WRITEABLE has been
a sustained property for PVO_MANANGED contexts from
what I see. (Not that I have any general understanding
of the code involved or what can be common for 32-bit
vs. what can not.)
END QUOTE

There was a KASSERT associated with the PGA_EXECUTABLE
handling. (I had a message about the 64-bit code vs.
32-bit code for the issue that I'll not quote here.)


Overall the issue was observed on both single-socket G4s/G3 and
dual-socket G4. Builds without MALLOC_PRODUCTION catch the problem
earlier/quicker. stress could be run in a way that it would end up
dying from jemalloc asserts, allowing fairly quick tests.

> Is this with an up-to-date userland? I do know there were some atomic issues in userland at one point, but they should all be sorted out now.

I've not retested with head -r365932 yet. But I'm unaware of
any vm_page_aflag_clear(????,PGA_WRITEABLE | PGA_EXECUTABLE)
like code having been put in place for 32-bit powerpc. Until
that has happened, things are not likely to be fixed in the
subject area. (PGA_WRITEABLE has such code in some places,
but there is no such PGA_EXECUTABLE code in mmu_oea.c .
mmu_moea64.c has such PGA_EXECUTABLE code in
moea64_pvo_remove_from_page_locked .)

>> Anyway, I've a bunch of SSDs to update so the basic
>> problem does not reappear if I grab another one.
>> 
> 

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)