The follow fatal trap seems to be caused by the vm locking changes:

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x3a
fault code              = supervisor write, page not present
instruction pointer     = 0x8:0xc027a13e
stack pointer           = 0x10:0xc35f0db8
frame pointer           = 0x10:0xc35f0e58
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 3 (vmdaemon)
kernel: type 12 trap, code=0
Stopped at      vm_fault1+0x122:        incw    0x3a(%eax)
db> t
vm_fault1(c033bd0c,c38a5000,1,0,c325adc0) at vm_fault1+0x122
vm_fault(c033bd0c,c38a5000,1,0,c325adc0) at vm_fault+0x8e
trap_pfault(c35f0ee4,0,c38a5bfc,0,bfc00000) at trap_pfault+0x1ce
trap(18,10,10,0,bfc00000) at trap+0x430
calltrap() at calltrap+0x5
--- trap 0xc, eip = 0xc02ac284, esp = 0xc35f0f24, ebp = 0xc35f0f24 ---
get_ptbase(c325faac,c325fa40,c325fa40,0,0) at get_ptbase+0x8
pmap_remove(c325faac,0,bfc00000) at pmap_remove+0x5c
vm_pageout_map_deactivate_pages(c325fa40,0) at vm_pageout_map_deactivate_pages+0xb0
vm_daemon(0,c35f0fa8) at vm_daemon+0x230
fork_exit(c0287834,0,c35f0fa8) at fork_exit+0x50
fork_trampoline() at fork_trampoline+0x8
db> sh r
cs                 0x8
ds                0x10
es                0x10
fs                0x18
ss                0x10
eax                  0
ecx         0xc35f0e04
edx                0x7
ebx                  0
esp         0xc35f0db8
ebp         0xc35f0e58
esi                0x1
edi         0xc38a5000
eip         0xc027a13e  vm_fault1+0x122
efl            0x10286
vm_fault1+0x122:        incw    0x3a(%eax)

This is with some missing locks added to swap_pager.c.

To duplicate this, try "dd if=/dev/zero of=/dev/null bs=N", where N is
about 12MB less than the memory size (just enough to use a few MB of

vm_fault() gets called with map == kernel_map for a pagefault in
get_ptbase().  This shouldn't happen and is soon fatal.  (The final
fault address of 0x3a is irrelevant.  It is just for the incw instruction.
%eax is fs.first_object which is null.  vm_map_lookup() refuses to
create a non-null object because the map is a system map.)

I once got a panic a little earlier in vm_pageout_map_deactivate_pages()
for attempting to access a vm_map_entry of ZENTRY_FREE.

atadump() always locked up attempting to dump from here.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to