From owner-freebsd-hackers Tue Oct 22 6:47: 3 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6DCC737B407 for ; Tue, 22 Oct 2002 06:47:00 -0700 (PDT) Received: from mail.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8925443E6A for ; Tue, 22 Oct 2002 06:46:59 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 22667 invoked from network); 22 Oct 2002 13:46:57 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 22 Oct 2002 13:46:57 -0000 Received: from laptop.baldwin.cx (laptop.baldwin.cx [192.168.0.4]) by server.baldwin.cx (8.12.6/8.12.6) with ESMTP id g9MDkon5062519; Tue, 22 Oct 2002 09:46:50 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3DB46B19.EC096B5F@mindspring.com> Date: Tue, 22 Oct 2002 09:46:54 -0400 (EDT) From: John Baldwin To: Terry Lambert Subject: Re: Kernel Panic Problems Cc: hackers@FreeBSD.org, Diego Wentz Antunes Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 21-Oct-2002 Terry Lambert wrote: > Diego Wentz Antunes wrote: >> >> I have been experiencing several kernel panics from differents >> >> situations, since a ls to just boot the kernel. >> >> I configured all the options in rc.conf to save the core dump from >> >> memory to HD and some of the results are >> >> here in the file panics. Above all I search at internet some information >> >> to try to explain this recursive panics >> >> and found that it could be some memory problem. Is there a way to make a >> >> hard test with memory? >> >> I'm uncertainty if it is the memory because the PC stayed turned on >> >> for 6 days without any problem! >> >> Any comments will be welcome! > > Panic #1: > --- >#0 dumpsys () at ../../kern/kern_shutdown.c:487 > 487 if (dumping++) { > (kgdb) where >#0 dumpsys () at ../../kern/kern_shutdown.c:487 >#1 0xc0164d4b in boot (howto=256) at ../../kern/kern_shutdown.c:316 >#2 0xc0165189 in panic (fmt=0xc02ae96c "%s") at ../../kern/kern_shutdown.c:595 >#3 0xc02623ab in trap_fatal (frame=0xc3e8be4c, eva=0) at > ../../i386/i386/trap.c:966 >#4 0xc0262059 in trap_pfault (frame=0xc3e8be4c, usermode=0, eva=0) at > ../../i386/i386/trap.c:859 >#5 0xc0261bff in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = > 671703040, tf_esi = 0, > tf_ebp = 0, tf_isp = -1008157064, tf_ebx = -1008183320, tf_edx = > -1087061161, tf_ecx = -1008183320, > tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = 0, tf_cs = 8, tf_eflags > = 66118, > tf_esp = -1071632535, tf_ss = 8}) at ../../i386/i386/trap.c:458 > (kgdb) quit > --- > > Is this a full backtrace? I don't see any way that the stack > could have started with "trap_pfault"... it had to be running > something to cause a page fault. It's a fault from userland perhaps. > Panic #2: > --- > ... >#8 0xc0261bff in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = > -1064400440, tf_esi = -1007800320, > tf_ebp = -1007805296, tf_isp = -1007805336, tf_ebx = 47288, tf_edx = > -1690778642, tf_ecx = 821789308, > tf_eax = -56600120, tf_trapno = 12, tf_err = 0, tf_eip = -1071249494, > tf_cs = 8, tf_eflags = 66070, > tf_esp = -1064405504, tf_ss = 2606062}) at ../../i386/i386/trap.c:458 >#9 0xc02607aa in generic_bcopy () >#10 0xc0247c30 in scstart (tp=0xc0879b00) at ../../dev/syscons/syscons.c:1285 >#11 0xc017c1e4 in ttstart (tp=0xc0879b00) at ../../kern/tty.c:1401 >#12 0xc017ccb9 in ttwrite (tp=0xc0879b00, uio=0xc3ee1ed4, flag=8323073) at > ../../kern/tty.c:1957 > ... > --- > > This one stops being possible at #9; specifically, there is no > version of syscons.c that, in scstart, calls generic_bcopy() > directly. The only functions it calls directly are q_to_b(), > which is a copy, but the function which does it is not static, > and has a global definition, and therefore should show up in > the stack trace. Similarly, the sc_puts() is also called. > > None of this really matches 4.4, 4.6, or -current syscons.c, > so more information is needed, but it's unlikely that syscons > has changed and changed back, so significantly. You need to > look at the code at dev/syscons/syscons.c:1285 in your own > source tree, which seems to differ significantly from the source > tree the rest of us are using. generic_bcopy() is an asm function which may not have a full frame. Thus, when gdb walks back over the stacktrace, it may skip the frame that called generic_bcopy() and go to the previous frame. ddb sometimes does a better job with backtraces for some reason. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message