> Date: Sat, 18 Apr 2026 14:35:49 +0200
> From: Jeremie Courreges-Anglas <[email protected]>
> 
> Hey hey,
> 
> First report below was obtained while running cvs co/up over NFS over
> smte0, disk is nvme.  This is after the pmap_growkernel() fix.

The first report is *exactly* what the pmap_growkernel() fix fixes.
So I suspect your kernel didn't have the fix yet.

The second one doesn't look familliar, but the "locking against
myself" panic is the result of an unexpected kernel page fault that
occurs shortly after allocating some new KVA.

> 
> (Second report below)
> 
> jupiter# mount
> /dev/sd0a on / type ffs (local)
> /dev/sd0j on /home type ffs (local, nodev, nosuid)
> /dev/sd0d on /tmp type ffs (local, nodev, nosuid)
> /dev/sd0f on /usr type ffs (local, nodev)
> /dev/sd0g on /usr/X11R6 type ffs (local, nodev)
> /dev/sd0h on /usr/local type ffs (local, nodev, wxallowed)
> /dev/sd0l on /usr/obj type ffs (local, nodev, nosuid)
> /dev/sd0o on /usr/ports type ffs (local, nodev, nosuid)
> /dev/sd0n on /usr/ports/pobj type ffs (local, nodev, nosuid)
> /dev/sd0m on /usr/src type ffs (local, nodev, nosuid)
> /dev/sd0e on /var type ffs (local, nodev, nosuid)
> m2:/home/cvs on /cvs type nfs (read-only, v3, udp, timeo=100, retrans=101)
> jupiter# t[0] == 0xffffffc0009d8b1e
> t[1] == 0xffffffc000300eaa
> t[2] == 0xffffffc080000000
> t[3] == 0xfffffffffffff000
> t[4] == 0x0000000eda410000
> t[5] == 0x000000000355c023
> t[6] == 0x00000000006e2dd9
> s[0] == 0xffffffc079405a60
> s[1] == 0xffffffc080000000
> s[2] == 0xffffffc07dfe9810
> s[3] == 0xffffffc000ae5dd8
> s[4] == 0xffffffc07dfe9830
> s[5] == 0xffffffc0009d8658
> s[6] == 0xffffffc07dfe9820
> s[7] == 0xffffffc07dfe9870
> s[8] == 0x0000000000000001
> s[9] == 0xffffffc07dfe9828
> s[10] == 0x0000000000000020
> s[11] == 0x0000000000000020
> a[0] == 0x8fb1268dcdae396c
> a[1] == 0x704ed94d4dae3964
> a[2] == 0x0000000000209000
> a[3] == 0x0000000000000004
> a[4] == 0xffffffc00032826c
> a[5] == 0x0000000000000004
> a[6] == 0x0000000000000000
> a[7] == 0x0000000000000000
> sepc == 0xffffffc00041fa4c
> sstatus == 0x0000000200000120
> stval == 0xffffffc080000000
> scause == 0x000000000000000f
> panic: Fatal page fault at 0xffffffc00041fa4c: 0xffffffc080000000
> Stopped at      panic+0xfc:     addi    a0,zero,256    TID    PID    UID     
> PR
> FLAGS     PFLAGS  CPU  COMMAND
> *277324  70736   1000        0x10          0    4  sshd-session
>   38813  49292      0     0x14000      0x200    1  nfsio
>   95797  84446      0     0x14000      0x200    3  softnet0
> panic() at panic+0xfc
> do_trap_supervisor() at do_trap_supervisor+0x1f4
> cpu_exception_handler_supervisor() at cpu_exception_handler_supervisor+0x7a
> pool_p_alloc() at pool_p_alloc+0xd0
> pool_get() at pool_get+0x88
> pmap_vp_enter() at pmap_vp_enter+0x7c
> pmap_enter() at pmap_enter+0x16c
> uvm_fault_lower() at uvm_fault_lower+0x1e6
> uvm_fault() at uvm_fault+0x12e
> do_trap_user() at do_trap_user+0x12c
> cpu_exception_handler_user() at cpu_exception_handler_user+0x7c
> end of kernel
> end trace frame: 0x1a00, count: 4
> https://www.openbsd.org/ddb.html describes the minimum info required in bug
> reports.  Insufficient info makes it difficult to find and fix bugs.
> ddb{4}> show uvm
> Current UVM status:
>   pagesize=4096 (0x1000), pagemask=0xfff, pageshift=12
>   4020453 VM pages: 13459 active, 23715 inactive, 1 wired, 3782288 free 
> (498644
>  zero)
>   freemin=134015, free-target=178686, inactive-target=0, wired-max=1340151
>   faults=498451, traps=3682715, intrs=10248416, ctxswitch=3203807 fpuswitch=0
>   softint=175252, syscalls=3150057, kmapent=14
>   fault counts:
>     noram=0, noanon=0, noamap=0, pgwait=0, pgrele=0
>     relocks=47506(1360), upgrades=53009(107) anget(retries)=288404(0), 
> amapcopy
> =41537
>     neighbor anon/obj pg=45399/115602, gets(lock/unlock)=99332/48875
>     cases: anon=269752, anoncow=18652, obj=89503, prcopy=8355, przero=112290
>   daemon and swap counts:
>     woke=0, revs=0, scans=0, obscans=0, anscans=0
>     busy=0, freed=0, reactivate=0, deactivate=0
>     pageouts=0, pending=0, nswget=0
>     nswapdev=1, swpskip=0
>     swpages=4259839, swpginuse=0, swpgonly=0 paging=0
>   kernel pointers:
>     objs(kern)=0xffffffc000a3a2e8
> ddb{4}> show bcstats
> Current Buffer Cache status:
> numbufs 67974 busymapped 2, delwri 3645
> kvaslots 5994 avail kva slots 5992
> bufpages 168243, dmapages 42878, dirtypages 14580
> pendingreads 2, pendingwrites 0
> highflips 82775, highflops 0, dmaflips 8614
> ddb{4}> bo re
> 
> The report below was obtained while running make -j8 release, I
> *think* the build was within gnu/usr.bin/perl.  Again pmap vp is on
> the way.  Sorry I can't give much more details right now, I'll be out
> for the day.
> 
> login: panic: mtx 0xffffffc02339bce8: locking against myself
> Stopped at      panic+0xfc:     addi    a0,zero,256    TID    PID    UID     
> PR
> FLAGS     PFLAGS  CPU  COMMAND
>  360909  18620     21         0x3          0    0  c++
> *315045  99142     21         0x3          0    1  c++
>   53391  57223     21         0x3          0    4  c++
>  177449  54051     21         0x3          0    7  c++
>  151115  79756     21         0x3          0    5  c++
>    6015  32842     21         0x3          0    6  c++
>  438278  33012     21         0x3          0    2  c++
>  432633  30138     21         0x3          0    3  c++
> panic() at panic+0xfc
> $x() at $x+0x88
> pmap_fault_fixup() at pmap_fault_fixup+0x3e
> do_trap_supervisor() at do_trap_supervisor+0x10e
> cpu_exception_handler_supervisor() at cpu_exception_handler_supervisor+0x7a
> uvm_addr_invoke() at uvm_addr_invoke+0x62
> uvm_map() at uvm_map+0x2c0
> km_alloc() at km_alloc+0x14c
> pmap_vp_page_alloc() at pmap_vp_page_alloc+0x5c
> pool_p_alloc() at pool_p_alloc+0x46
> pool_do_get() at pool_do_get+0xec
> --db_more--t[0] == 0xffffffc0009d8204
> t[1] == 0xffffffc0005bb92e
> t[2] == 0xfffffffffffff000
> t[3] == 0x000000006c4de780
> t[4] == 0x0000000108d98000
> t[5] == 0x0000000080a43400
> t[6] == 0x0000000080a436b0
> s[0] == 0xffffffc082b515d0
> s[1] == 0x0000000000000000
> s[2] == 0x0000000000004000
> s[3] == 0xffffffc082b51728
> s[4] == 0xffffffc082b516a8
> s[5] == 0xffffffc000acd208
> s[6] == 0x0000000000000003
> s[7] == 0x0000000000000000
> s[8] == 0x0000000000001000
> s[9] == 0xffffffc0233b3e80
> s[10] == 0xffffffc082b516a0
> s[11] == 0x0000000000001323
> a[0] == 0x00000000e89c6080
> a[1] == 0xffffffc0233c06f8
> a[2] == 0x0000000000000183
> a[3] == 0xffffffc082b516a0
> a[4] == 0xffffffc082b51728
> a[5] == 0x0000000000004000
> a[6] == 0x0000000000001000
> a[7] == 0x0000000000000000
> sepc == 0xffffffc000550c96
> sstatus == 0x0000000200000120
> stval == 0x00000000e89c6080
> scause == 0x000000000000000d
> pool_get() at pool_get+0x88
> pmap_vp_enter() at pmap_vp_enter+0x7c
> n t  e r  ( )  anpt e r +0 x 1 6 c
>  eanndic :   F  attraalcpe a g e   f a u lt  a  t   0  x f f f f f 
> frfacm0e0:0 05x5f0  cf9f6f:f 0fxc0e8829
> 
> bc64058c04
> 0, count: 0
> https://www.openbsd.org/ddb.html describes the minimum info required in bug
> reports.  Insufficient info makes it difficult to find and fix bugs.
> ddb{1}> sh panic
>  cpu0: Fatal page fault at 0xffffffc000550c96: 0xe89c6080
> *cpu1: mtx 0xffffffc02339bce8: locking against myself
> ddb{1}> tr
> panic() at panic+0xfc
> $x() at $x+0x88
> pmap_fault_fixup() at pmap_fault_fixup+0x3e
> do_trap_supervisor() at do_trap_supervisor+0x10e
> cpu_exception_handler_supervisor() at cpu_exception_handler_supervisor+0x7a
> uvm_addr_invoke() at uvm_addr_invoke+0x62
> uvm_map() at uvm_map+0x2c0
> km_alloc() at km_alloc+0x14c
> pmap_vp_page_alloc() at pmap_vp_page_alloc+0x5c
> pool_p_alloc() at pool_p_alloc+0x46
> pool_do_get() at pool_do_get+0xec
> pool_get() at pool_get+0x88
> pmap_vp_enter() at pmap_vp_enter+0x7c
> pmap_enter() at pmap_enter+0x16c
> uvm_fault_lower() at uvm_fault_lower+0x1e6
> uvm_fault() at uvm_fault+0x12e
> do_trap_user() at do_trap_user+0x12c
> cpu_exception_handler_user() at cpu_exception_handler_user+0x7c
> end of kernel
> end trace frame: 0x120fd8000, count: -18
> ddb{1}> bo re
> rebooting...
> 
> 
> -- 
> jca
> 

Reply via email to