Date: Mon, 21 May 2001 05:09:00 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: current@freebsd.org Cc: alfred@freebsd.org Subject: another new vm/swap panic Message-ID: <Pine.BSF.4.21.0105210445300.46958-100000@besplex.bde.org>
next in thread | raw e-mail | index | archive | help
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) db> 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 swap). 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. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0105210445300.46958-100000>