Unfortunatly thre is a codepath in the KSE system that has not
been tested, due to a bug in the UVM system. Jeff fixed the UVM
problem for me ysesterday but that means that the following
stack trace (representing the code path in question) is now
used and teh resulting panic happens...
Is there a VM expert here that understands the mapping system who I can
tap to help me figure out what I did wrong..
This is a clasic case of one bug hiding another..
Debugger(c030265c) at Debugger+0x45
panic(c0328ee0,1d,1,c0b889d8,1) at panic+0x74
vm_page_free_toq(c0b889d8,c0b889d8,40,c0b889d8,cca32c14) at
vm_page_free_toq+0xd0
vm_page_free(c0b889d8,c0b889d8,0) at vm_page_free+0x15
pmap_dispose_thread(c2a25000,cca32c4c,c02b2fed,c2a25000,b8) at
pmap_dispose_thread+0x84
thread_fini(c2a25000,b8) at thread_fini+0x28
zone_drain(c0ede000) at zone_drain+0x29d
zone_foreach(c02b2d50,cca32d08,c02b0924,c03542c0,1) at zone_foreach+0x2f
uma_reclaim(c03542c0,1,c03296c2,287,c03542c0) at uma_reclaim+0x12
vm_pageout_scan(0,c1cf10c0,cca32d34,c019066c,0) at vm_pageout_scan+0x30
vm_pageout(0,cca32d48,c1cf10c0,c02b13f4,0) at vm_pageout+0x22d
fork_exit(c02b13f4,0,cca32d48) at fork_exit+0xd8
fork_trampoline() at fork_trampoline+0x37
db> gdb
Next trap will enter GDB remote protocol mode
db> s
Stopped at Debugger+0x4e: leave
db> x/s 0xc0328ee0
vm_object_print_pages_cmd+0x3c4: vm_page_free: invalid wire count
(%d), pindex: 0x%lx
if (m->wire_count != 0) {
if (m->wire_count > 1) {
panic("vm_page_free: invalid wire count (%d),
pindex: 0x%lx",
m->wire_count, (long)m->pindex);
}
panic("vm_page_free: freeing wired page\n");
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
