Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 19 Jan 2003 20:37:09 -0500 (EST)
From:      Robert Watson <rwatson@freebsd.org>
To:        "Russell L. Carter" <rcarter@pinyon.org>
Cc:        freebsd-current@freebsd.org
Subject:   Re: STABLE->CURRENT rl fails
Message-ID:  <Pine.NEB.3.96L.1030119202919.67385I-100000@fledge.watson.org>
In-Reply-To: <20030118001302.E726518F@pinyon.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On Fri, 17 Jan 2003, Russell L. Carter wrote:

> rl0: discard oversize frame (ether type fbf7 flags 3 len 2992 > max 1514)
> rl0: discard oversize frame (ether type fbf7 flags 3 len 2992 > max 1514)
> rl0: discard oversize frame (ether type 2e3d flags 3 len 55442 > max 1514)
> rl0: discard oversize frame (ether type 904 flags 3 len 36106 > max 1514)
> 
> Fatal trap 12: page fault while in kernel mode
> fault virtual address	= 0x46
> fault code		= supervisor read, page not present
> instruction pointer	= 0x8:0xc02f19c0
> stack pointer	        = 0x10:0xd9344ca4
> frame pointer	        = 0x10:0xd9344cbc
> 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		= 832 (reboot)
> trap number		= 12
> panic: page fault

I'm probably no good on the if_rl and ACPI issues, but I can give this one
a try.  This panic is a NULL pointer dereference, apparently in the
shutdown.  If this is reproduceable, here's what would be most helpful to
debug it: take a copy of the GENERIC kernel config, and make sure it
contains debugging symbols.  I.e., the kernel configuration contains
"makeoptions DEBUG=-g".  Configure kernel dumps using the dumpdev option
in /etc/rc.conf -- typically people use their swap device.  You may
already have debugging symbols for your kernel if you're using GENERIC
from -current.  When the crash occurs, a dump will be performed, and then
when you boot up next, it will be saved in /var/crash (assuming you have
room -- if it's smaller than your system memory, symlink to /usr/crash and
create an appropriate target directory).  Finally, run:

  gdb /usr/obj/.../kernel.debug /var/crash/vmcore.0

(replace the first path with the path to your kernel target build
directory)
(replace the second path with the most recent kernel dump)

Type in "backtrace" to generate a trace, and respond to this e-mail with
the trace.

Another popular debugging option is to compile your kernel with "options
DDB" which will allow you access to the live kernel debugger, which can be
used to generate traces on a panic.  However, that's most useful if you
have a serial console, and can copy/paste the results into an e-mail. 
There should be a fair amount of information on kernel debugging in the
handbook if you need guidance on the details on how to do the above.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org      Network Associates Laboratories



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.NEB.3.96L.1030119202919.67385I-100000>