In preparation for that, I've been compiling latest unmodified source for kernel and /usr/src but am unable to reproduce a panic, even at make -j32. I'll keep trying.
On Wed, Nov 20, 2024 at 5:06 PM George Koehler <kern...@gmail.com> wrote: > > Eric, or anyone with a powerpc64 with a lot of ram, does this diff > prevent panics in uvm_fault or crashes on "trap type 300"? > > I did reproduce a "trap type 300" with 8g ram once on 2024-11-05, but > failed to reproduce it again. I have now found some code in > powerpc64's pte_insert that might put a page table entry in the wrong > bucket, but only if the primary and secondary buckets are both full. > With only 8g ram, my powerpc64 rarely fills these buckets before it > starts swapping. I'm trying to fix a problem that almost never > happens to me. > --gkoehler > > Index: arch/powerpc64/powerpc64/pmap.c > =================================================================== > RCS file: /cvs/src/sys/arch/powerpc64/powerpc64/pmap.c,v > diff -u -p -r1.62 pmap.c > --- arch/powerpc64/powerpc64/pmap.c 4 Jun 2024 17:31:59 -0000 1.62 > +++ arch/powerpc64/powerpc64/pmap.c 17 Nov 2024 03:20:57 -0000 > @@ -816,8 +816,8 @@ pte_insert(struct pte_desc *pted) > pted->pted_va &= ~(PTED_VA_HID_M|PTED_VA_PTEGIDX_M); > pted->pted_va |= off & (PTED_VA_PTEGIDX_M|PTED_VA_HID_M); > > - idx ^= (PTED_HID(pted) ? pmap_ptab_mask : 0); > - pte = pmap_ptable + (idx * 8); > + pte = pmap_ptable; > + pte += (idx ^ (PTED_HID(pted) ? pmap_ptab_mask : 0)) * 8; > pte += PTED_PTEGIDX(pted); /* increment by index into pteg */ > > if ((pte->pte_hi & PTE_WIRED) == 0)
