On Tue, 24 Dec 2024 07:34:07 -0800
Eric Grosse <gro...@gmail.com> wrote:
> ... This is from a kernel built
> from current sources via AnonCVS with option WITNESS....
Thanks for reporting the problem, and I'm sorry that I didn't reply
sooner. Your kernel from 24 Dec looks like a kernel without WITNESS,
> ddb{1}> show all locks
> No such command
> ddb{1}> show witness
> No such command
> ddb{1}> show locks
> No such command
These commands exist in a WITNESS kernel. I would check for kernel
diffs (cd /sys && cvs -q diff). If you enable WITNESS, you would have
a diff in arch/powerpc64/conf/GENERIC.MP to uncomment option WITNESS.
If you have other diffs, you might clean them (cvs up -C); I might
have given you some obsolete diffs. After you edit conf/GENERIC.MP,
or after you cvs up, you should "make config" in compile/GENERIC.MP.
If "make config" says,
Kernel options have changed -- you must run "make clean"
then also "make clean".
> ddb{1}> mach ddbcpu 3
> Stopped at _rb_remove+0x36c: ld r4,8(r3)
> _rb_remove+0x36c
> uvm_pmr_get1page+0x130
> ...
> ddb{3}> show registers
> r3 0
cpu3 entered ddb when the kernel tried to read unmapped memory at
8(r3); the 0 in r3 is a NULL pointer. The kernel trap handler (for
reading unmapped memory) does not set a panic string. The panic on
cpu1 looks like a side effect of cpu3 disabling the locks as cpu3
entered ddb.
The trace from cpu3, beginning at _rb_remove+0x36c, stops at
uvm_fault+0x118. I can't see what called uvm_fault, but it was
probably the user trap handler for the "compile" process on cpu3.
(The command "ddb{3}> trace" might have shown the trap handler.) The
user trap tried to map in some anonymous memory, but for some
mysterious reason, it caused a kernel trap by reading NULL.
I make a guess, which might be wrong. This uvm_fault call might come
from a hash collision in pmap_ptable. I had fixed a problem with
hash collisions in pmap.c r1.63 (2024/11/27), but this might be a
different problem. I might need to bypass uvm_fault by adding code to
reinsert PTEs that fall out from hash collisions. The macppc kernel
has this code in pte_spill_v, but powerpc64 does not have it yet.
--gkoehler
