On Wed, 26 May 2004, Vivek Khera wrote:
> I'm loading some data into a postgres database and I keep
> crashing/locking up my box. I hooked up a serial console to try to
> figure it out. Here is what the console displayed. What does this
> mean? Can it be hardware or is it most likely software?
There's a fairly useful section in the Handbook on preparing bug reports,
attaching debuggers, performing core dumps, etc. Depending on how moved
you are to hack kernels, varying degrees of that might or might not be
appealing :-).
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0x0
> fault code = supervisor write, page not present
> instruction pointer = 0x8:0xc0230fee
> stack pointer = 0x10:0xc0276ed8
> frame pointer = 0x10:0xc0276ed8
> 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 = Idle
> interrupt mask = none
> trap number = 12
> panic: page fault
This is a NULL pointer dereference in some piece of code. The instruction
pointer is 0xc0230fee, which if you have a kernel with debugging symbols,
you can convert into a source file and line number (see the handbook for
details). If you don't have, or can't get a kernel with debugging
symbols, you can use 'nm' on your kernel to look for the symbols on
either
side of the address -- the symbol before is the function the crash occurs
in. That information can be used to help determine what has taken place.
If this is a reproduceable problem, try compiling DDB into the kernel and
using a serial console to capture a stack trace (instructions in the
handbook), as that should be most helpful.
Regarding kernel bug or hardware problem: it could be either, as NULL
pointer dereferences can be the result of code that isn't written to
handle an error case that occurs in the real world, a logic error, or can
occur if your hardware isn't operating to specification, or is failing in
some or another form. Knowing what function the fault takes place in
would go a long way in resolving that, however.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org Senior Research Scientist, McAfee Research
>
> syncing disks...
>
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0x30
> fault code = supervisor read, page not present
> instruction pointer = 0x8:0xc01f4830
> stack pointer = 0x10:0xc0276d04
> frame pointer = 0x10:0xc0276d0c
> 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 = Idle
> interrupt mask = bio
> trap number = 12
> panic: page fault
> Uptime: 2h15m33s
> Automatic reboot in 15 seconds - press a key on the console to abort
> Rebooting...
>
>
>
> A few days ago I noticed a "write timeout resetting device" on
the ad1
> disk. Both IDE drives are on the same controller.
>
> This is running FreeBSD 4.10-PRERELEASE #6: Wed May 26 13:23:05 EDT
> 2004, but was cvsup'd yesterday. The CPU is an AMD Duron 850 with
> 1.5GB RAM.
>
> What should I look to fix on this sytem?
>
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to
"freebsd-stable-unsubscribe@freebsd.org"