Re: Another pmap panic

[mlh%goathill.org@localhost (MLH)]

Chavdar wrote:
> Overnight, while doing pkg_rolling-replace, my 'server' got:
> ...
> panic: kernel diagnostic assertion "ptp->wire_count == 1" failed: file
>       "/home/sysbuild/src/sys/arch/x86/x86/pmap.c", line 2232
> 
> cpu0: Begin traceback...
> vpanic() at netbsd:vpanic+0x178
> kern_assert() at netbsd:kern_assert+0x48
> pmap_unget_ptp() at netbsd:pmap_unget_ptp+0x1f1
> pmap_get_ptp() at netbsd:pmap_get_ptp+0x300
> pmap_enter_ma() at netbsd:pmap_enter_ma+0x6fb
> pmap_enter_default() at netbsd:pmap_enter_default+0x29
> uvm_fault_internal() at netbsd:uvm_fault_internal+0xf2e
> trap() at netbsd:trap+0x50a
> --- trap (number 6) ---
> 7f7eec2007e0:
> cpu0: End traceback...
> 
> dumping to dev 168,2 (offset=8, size=5225879):

I just got another one :

[ 101789.993512] panic: kernel diagnostic assertion "ptp->wire_count == 1" failed: file "/usr/src/sys/arch/x86/x86/pmap.c", line 2232 
[ 101789.993512] cpu1: Begin traceback...
[ 101789.993512] vpanic() at netbsd:vpanic+0x178
[ 101789.993512] kern_assert() at netbsd:kern_assert+0x48
[ 101789.993512] pmap_unget_ptp() at netbsd:pmap_unget_ptp+0x1f1
[ 101789.993512] pmap_get_ptp() at netbsd:pmap_get_ptp+0x300
[ 101789.993512] pmap_enter_ma() at netbsd:pmap_enter_ma+0x6fb
[ 101789.993512] pmap_enter_default() at netbsd:pmap_enter_default+0x29
[ 101789.993512] uvm_fault_lower_enter() at netbsd:uvm_fault_lower_enter+0x111
[ 101789.993512] uvm_fault_internal() at netbsd:uvm_fault_internal+0x12b1
[ 101789.993512] trap() at netbsd:trap+0x50a
[ 101789.993512] --- trap (number 6) ---
[ 101789.993512] 6fa90c321352:
[ 101789.993512] cpu1: End traceback...

[ 101789.993512] dumping to dev 0,1 (offset=1159, size=1044333):

Built two days ago - NetBSD 9.99.50 Wed Mar 18 12:46:17

Just before it coredumped, I saw that kmem-00192 showed almost 10
million requests and only 465 releases.  I just rebooted and:
Name        Size Requests Fail Releases Pgreq Pgrel Npage Hiwat Minpg Maxpg Idle
kmem-00192   256    82638    0        0  5165     0  5165  5165     0   inf    0

And vmstat showed that fre memory was down to under 4M, though the
box was essentially idle.

It was mentioned that radeondrmkms might have a big memory leak.
Every time the display changes, such as even moving the mouse, the
number of kmem-00192 requests goes way up and the number of releases
pretty much never changes.