From owner-freebsd-questions Mon Mar 30 17:11:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA15973 for freebsd-questions-outgoing; Mon, 30 Mar 1998 17:11:37 -0800 (PST) (envelope-from owner-freebsd-questions@FreeBSD.ORG) Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA15839 for ; Mon, 30 Mar 1998 17:10:22 -0800 (PST) (envelope-from grog@lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.8.7/8.8.5) with ESMTP id KAA01054; Tue, 31 Mar 1998 10:40:02 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.8.8/8.8.7) id KAA02384; Tue, 31 Mar 1998 10:40:01 +0930 (CST) (envelope-from grog) Message-ID: <19980331104001.07907@freebie.lemis.com> Date: Tue, 31 Mar 1998 10:40:01 +0930 From: Greg Lehey To: "M. Monninger" , questions@FreeBSD.ORG Subject: Re: spontaneous reboot / panic References: <3.0.5.32.19980330171937.0098be20@pop.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <3.0.5.32.19980330171937.0098be20@pop.primenet.com>; from M. Monninger on Mon, Mar 30, 1998 at 05:19:37PM +0000 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 30 March 1998 at 17:19:37 +0000, M. Monninger wrote: > At 03:49 PM 3/30/98 -0800, Doug White wrote: >> >> Should be a lot more to this. A panic in idle state would be *very* >> suspicious; it may be a hardware problem, bad memory or corrupted swap. >> > Here's one from my system: > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x4 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xf0129f5a > stack pointer = 0x10:0xefbffcac > frame pointer = 0x10:0xefbffcb8 > 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 = 4254 (find) > interrupt mask = > panic: page fault > > It does this every once in a whle, maybe once a month. I also see disk > errors every few days. Hmmm...wonder if it's related??? Related to the disk errors, or to other panics? It could be related to the disk errors, but there's no reason to believe that any of these panics are related. This is one FreeBSD equivalent of the dreaded "General Protection Error" you see so often with Microsoft. It means that something has gone wrong with the kernel's addressing, and that no specific routines exist to handle it. The only reliable way to find out what is going on here is a dump. The only useful way to analyse a dump is to build a debug kernel and use that kernel for the analysis. These are the steps (page 290 of "The Complete FreeBSD", second edition): To prepare yourself for possible problems, you should build kernels which include debug symbols. The resultant kernel is about 10 MB in size, but it will make debugging with ddb (the kernel debugger) or gdb much easier. Even if you don't intend to do this yourself, the information will be of great use to anybody you may call in to help. Building a debug kernel is pretty much the same process as building a normal kernel. Here are the differences: o Run config with the -g option: # config -g FREEBIE o After building the kernel, rename it to kernel.gdb: # mv kernel kernel.gdb o Make a copy of kernel.gdb called kernel, and strip debug symbols: # cp kernel.gdb kernel # strip -d kernel o Install the kernel. You should also enable dumping in /etc/rc.conf. When you have a dump (in /var/crash), run gdb against it: # gdb -k kernel.gdb vmcore.21 GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.16 (i386-unknown-freebsd), Copyright 1996 Free Software Foundation, Inc... IdlePTD 2be000 initial pcb at 25b6d8 panicstr: pmap_zero_page: CMAP busy panic messages: panic: pmap_zero_page: CMAP busy dumping to dev 20001, offset 172032 dump 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 --- During symbol reading, debug info mismatch between compiler and debugger. #0 boot (howto=0x104) at ../../kern/kern_shutdown.c:286 286 dumppcb.pcb_cr3 = rcr3(); (kgdb) bt #0 boot (howto=0x104) at ../../kern/kern_shutdown.c:286 #1 0xf011c1e7 in panic (fmt=0xf01013e8 "from debugger") at ../../kern/kern_shutdown.c:426 #2 0xf0101405 in db_panic (addr=0xf01de574, have_addr=0x0, count=0x1, modif=0xf2ac3a40 "") at ../../ddb/db_command.c:432 #3 0xf01012e5 in db_command (last_cmdp=0xf0244aa4, cmd_table=0xf0244904, aux_cmd_tablep=0xf0258a34) at ../../ddb/db_command.c:332 #4 0xf0101472 in db_command_loop () at ../../ddb/db_command.c:454 #5 0xf0103b33 in db_trap (type=0xa, code=0x0) at ../../ddb/db_trap.c:71 #6 0xf01de341 in kdb_trap (type=0xa, code=0x0, regs=0xf2ac3b2c) at ../../i386/i386/db_interface.c:157 #7 0xf01eb7c8 in trap (frame={tf_es = 0x10, tf_ds = 0x10, tf_edi = 0x0, tf_esi = 0xf01e9a0e, tf_ebp = 0xf2ac3b70, tf_isp = 0xf2ac3b54, tf_ebx = 0x100, tf_edx = 0xf01de535, tf_ecx = 0x0, tf_eax = 0x12, tf_trapno = 0xa, tf_err = 0x0, tf_eip = 0xf01de574, tf_cs = 0x8, tf_eflags = 0x346, tf_esp = 0xf01de525, tf_ss = 0xf011c17c}) at ../../i386/i386/trap.c:474 #8 0xf01de574 in Debugger (msg=0xf011c17c "panic") at ../../i386/i386/db_interface.c:317 #9 0xf011c1de in panic (fmt=0xf01e9a0e "pmap_zero_page: CMAP busy") at ../../kern/kern_shutdown.c:424 #10 0xf01e9a3f in pmap_zero_page (phys=0xee3000) at ../../i386/i386/pmap.c:2716 #11 0xf01c84cf in vm_fault (map=0xf02667e4, vaddr=0xf1e30000, fault_type=0x1, fault_flags=0x0) at ../../vm/vm_fault.c:532 #12 0xf01eba28 in trap_pfault (frame=0xf2ac3ca0, usermode=0x0) at ../../i386/i386/trap.c:724 #13 0xf01eb6a7 in trap (frame={tf_es = 0xf0140010, tf_ds = 0xf2ac0010, tf_edi = 0x80779eb9, tf_esi = 0xf1e2e000, tf_ebp = 0xf2ac3d18, tf_isp = 0xf2ac3cc8, tf_ebx = 0x2000, tf_edx = 0xf07d2000, tf_ecx = 0x2000, tf_eax = 0x2000, tf_trapno = 0xc, tf_err = 0x0, tf_eip = 0xf2a9b830, tf_cs = 0xf2a90008, tf_eflags = 0x10216, tf_esp = 0x4000, tf_ss = 0x150}) at ../../i386/i386/trap.c:363 #14 0xf2a9b830 in ?? () #15 0xf2a996b4 in ?? () #16 0xf01363aa in biodone (bp=0xf05a4694) at ../../kern/vfs_bio.c:1838 #17 0xf01b1fa4 in scsi_done (xs=0xf04e1e80) at ../../scsi/scsi_base.c:447 #18 0xf01f22db in aha_done (aha=0xf04e4000, ccb=0xf04e4b18) at ../../i386/isa/aha1542.c:947 #19 0xf01f1dc9 in ahaintr (unit=0x0) at ../../i386/isa/aha1542.c:753 #20 0xf01ea59a in generic_bcopy () #21 0xf01c85e1 in vm_fault (map=0xf29f0440, vaddr=0x5f000, fault_type=0x3, fault_flags=0x8) at ../../vm/vm_fault.c:625 #22 0xf01eba0e in trap_pfault (frame=0xf2ac3fbc, usermode=0x1) at ../../i386/i386/trap.c:716 #23 0xf01eb523 in trap (frame={tf_es = 0xefbf0027, tf_ds = 0xf2a80027, tf_edi = 0xe5513, tf_esi = 0x2, tf_ebp = 0xefbfdaec, tf_isp = 0xf2ac3fe4, tf_ebx = 0x0, tf_edx = 0xffffffff, tf_ecx = 0xc99b0, tf_eax = 0x2, tf_trapno = 0xc, tf_err = 0x7, tf_eip = 0x1f01c, tf_cs = 0x1f, tf_eflags = 0x10246, tf_esp = 0xefbfdae0, tf_ss = 0x27}) at ../../i386/i386/trap.c:287 #24 0x1f01c in ?? () This looks pretty much like gibberish--see the online handbook for more details. In particular, though, the last part is what we need: where did this happen? The command (kgdb) bt tells gdb to give you a backtrace of the function calls. The #1, #2 and so on are the frame numbers. In this particular dump, frames #13 and #23 are trap frames. As the name in frames #12 and #22 show, in each case it was a page fault. Nobody's asking you to solve this dump, of course (I wish I could), but the information will usually give an accurate idea of what caused it. Greg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message