Date: Mon, 04 Aug 2003 02:00:18 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: freebsd-alpha@freebsd.org Subject: Re: another vm/pmap alpha panic Message-ID: <3F2E20A2.5D45C4F3@mindspring.com> References: <16173.23401.983536.279158@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Andrew Gallatin wrote: > panic: pmap_remove_all: pv_table for 8306000 is inconsistent > Stack backtrace: > db_print_backtrace() at db_print_backtrace+0x18 > backtrace() at backtrace+0x2c > panic() at panic+0x148 > pmap_remove_all() at pmap_remove_all+0xfc > vm_object_page_remove() at vm_object_page_remove+0x1b0 > vm_map_delete() at vm_map_delete+0x438 > vm_map_remove() at vm_map_remove+0x64 > exit1() at exit1+0x950 > sys_exit() at sys_exit+0x88 > syscall() at syscall+0x398 > XentSys() at XentSys+0x64 > --- syscall (1) --- > --- user mode --- > > Of course, the crashdump is not usable. Despite what Greg says, it's useful to use the gdb "list" command against the binary addresses to determine the line of code where your kernel is actually failing. Specifically, gdb -k kernel.debug (gdb) list *(vm_object_page_remove+1b0) (One had to wonder why the "list" command exists, if it's as useless as Greg claims). -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F2E20A2.5D45C4F3>