Date: Thu, 13 Jan 2005 20:46:24 +1100 From: Peter Jeremy <PeterJeremy@optushome.com.au> To: Rick Updegrove <dislists@updegrove.net> Cc: freebsd-stable@freebsd.org Subject: Re: 5.3-RELEASE crashes during make buildworld (and other problems) Message-ID: <20050113094624.GD79646@cirb503493.alcatel.com.au> In-Reply-To: <41E59844.6000805@updegrove.net> References: <41E36760.2090609@updegrove.net> <44fz18m5k4.fsf@be-well.ilk.org> <41E59844.6000805@updegrove.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2005-Jan-12 13:36:04 -0800, Rick Updegrove wrote:
>Fatal trap 12: page fault while in kernel mode
>fault virtual address = 0x4d
>fault code = supervisor read, page not present
>instruction pointer = 0x8:0xc061c642
That's a NULL pointer dereference. It's not necessarily hardware.
>rickup@nothing$ nm -n /boot/kernel | grep c061c642
>nm: Warning: '/boot/kernel' is not an ordinary file
Two problems:
1) The kernel is /boot/kernel/kernel (sysctl kern.bootfile)
2) You're extremely unlikely to find a symbol at that address.
What you need to do is
$ nm -n `sysctl kern.bootfile` | less
and search for the symbol closest to but no greater than 0xc061c642
This still isn't enough information to reveal anything useful. As a
minimum, you need to enable DDB ("options DDB" and "options KDB") and
get a backtrace after the panic. If you don't already have one, a
serial console will make things much easier. A crashdump or gdb
session would be much better.
>> Hardware problems would be my first suspicion here.
>
>Me too... if it were not for the fact 5.3-RELEASE is the only OS that
>has problems on this hardware.
That doesn't totally rule out hardware. Pattern-sensitive memory
problems may not show up on different operating systems (or even
different kernels). That said, based on the trap information, I'd
look at a software cause first.
--
Peter Jeremy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050113094624.GD79646>