Date: Mon, 11 Aug 2003 16:53:33 +0200 (CEST) From: Lukas Ertl <l.ertl@univie.ac.at> To: freebsd-current@freebsd.org Subject: Re: New panics Message-ID: <20030811164918.P224@pcle2.cc.univie.ac.at> In-Reply-To: <20030810221335.G582@korben.in.tern> References: <20030810221335.G582@korben.in.tern>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 10 Aug 2003, Lukas Ertl wrote: > 5.1-CURRENT FreeBSD 5.1-CURRENT #12: Wed Aug 6 21:49:32 CEST 2003 > > Fatal trap 12: page fault while in kernel mode > cpuid = 3; lapic.id = 07000000 > fault virtual address = 0xbfcb09a0 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc035ea65 > stack pointer = 0x10:0xe0ba4acc > frame pointer = 0x10:0xe0ba4ad8 > 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 = 40 (bufdaemon) > trap number = 12 > panic: page fault > cpuid = 3; lapic.id = 07000000 > boot() called on cpu#3 > > syncing disks, buffers remaining... > > Fatal trap 12: page fault while in kernel mode > cpuid = 3; lapic.id = 07000000 > fault virtual address = 0x24 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc01f8ddb > stack pointer = 0x10:0xdf150b74 > frame pointer = 0x10:0xdf150b88 > 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 (g_up) > trap number = 12 > panic: page fault > cpuid = 3; lapic.id = 07000000 > boot() called on cpu#3 > Uptime: 1d0h49m45s > Dumping 1023 MB > 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 992 1008 > --- Forget that backtrace, at least for this current problem, it seems like the kernel panicked inside the coredump routine again, and I got the coredump of the second panic :-/. (This would correspond to the instruction pointer of the second panic, which shows as "propagate_priority" in "nm kernel". If I run "nm /usr/local/crash/kernel.3 | grep c035e" (the IP of the first panic message), I get this: c035ef70 t i386_protection_init c035e030 T pmap_change_wiring c035ecf0 T pmap_clear_modify c035ee30 T pmap_clear_reference c035e0a0 T pmap_copy c035e690 T pmap_copy_page c035e9f0 T pmap_is_modified c035efb0 T pmap_mapdev c035e7e0 T pmap_page_exists_quick c035ea90 T pmap_page_protect c035e840 T pmap_remove_pages c035ebf0 T pmap_ts_referenced c035e390 T pmap_zero_page c035e4c0 T pmap_zero_page_area c035e5f0 T pmap_zero_page_idle c035e350 t pmap_zpi_switchin12 c035e370 t pmap_zpi_switchin2 c035e380 t pmap_zpi_switchin3 Closest comes pmap_is_modified, I guess. regards, le -- Lukas Ertl eMail: l.ertl@univie.ac.at UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030811164918.P224>