Date: Wed, 23 Sep 2020 16:30:55 -0700 From: Mark Millard <marklmi@yahoo.com> To: Brandon Bergren <bdragon@FreeBSD.org> Cc: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: head -r365932 on PowerMac G5 (2 dual-core sockets): Crashes before login prompt if powerd is enabled in /etc/rc.conf Message-ID: <822366D0-375E-4B1F-BA1C-B78032391840@yahoo.com> In-Reply-To: <37a949c0-611f-4700-9b37-4bc0c27e7b5c@www.fastmail.com> References: <52783D16-5DCA-45BC-9238-2518326454A1@yahoo.com> <6E99EE39-D2B8-415A-A5BF-823C0F0C22D6@yahoo.com> <cd9d2b72-219f-4550-a437-4ac3aa1da66d@www.fastmail.com> <AF27169A-00FC-4984-83C2-307EA885D7A1@yahoo.com> <11fe573a-24c3-47be-95ed-c601ec54f168@www.fastmail.com> <E23CF7F6-B69C-44C7-B356-4AB65E011268@yahoo.com> <B4D16405-1B0C-4500-866F-75F32FED235A@yahoo.com> <92f57afb-33cb-4d38-be17-4b8c81cb9c89@www.fastmail.com> <D6DC1C60-E50D-4A12-9F3B-6CEBA6A76748@yahoo.com> <6a0ade9d-26f2-4448-b066-0b06ed3ba5ef@www.fastmail.com> <9D4314E7-92C9-4BDD-B023-8C9BC3DCCAB0@yahoo.com> <E1EEDF91-42B1-4319-9513-7DE6FDE6E5F3@yahoo.com> <F1808C34-3C1A-44DC-BB23-2F0959AC64F5@yahoo.com> <db3de197-eb27-40ef-89ac-433b7fa72fe4@www.fastmail.com> <5E79BB07-D54B-4A8E-B592-F480211D0B92@yahoo.com> <88052e3f-4b79-45ca-8ebb-9fc19cbc558b@www.fastmail.com> <07E0C1EE-647C-4BFD-A60F-71B02EA3FB13@yahoo.com> <4e63a5ee-a452-4f04-99f2-3ab99c68944c@www.fastmail.com> <B8000BA4-572E-4ADC-B7DB-2E61E961EB6B@yahoo.com> <325C90D0-B338-40F6-AEB3-DAC8A90A3E94@yahoo.com> <37a949c0-611f-4700-9b37-4bc0c27e7b5c@www.fastmail.com>
index | next in thread | previous in thread | raw e-mail
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)home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?822366D0-375E-4B1F-BA1C-B78032391840>