Fatal trap 12: page fault while in kernel mode

Sean Farley sean-freebsd at farley.org
Mon Aug 23 14:26:18 PDT 2004

On Mon, 23 Aug 2004, Kevin Brunelle wrote:

> Alright, this is driving me nuts.  For a little while there I could
> not get the system to panic -- it would spontaniously reboot when
> running a GL program instead of panic.  This afternoon it finally
> panic'd (who would think that would be something I want to see but it
> was).

If this is how I got most of my panics, this little script running in
two different xterms helped decrease the time to panic.  It got my
system to panic a lot with the older nvidia drivers.


# Try with and without.

/bin/rm -f glxinfo.core

while [ 1 = 1 ]; do
 	/usr/X11R6/bin/glxinfo >& /dev/null

 	if [ -e glxinfo.core ]; then
 		echo "Core found."
 		/bin/rm -f glxinfo.core

This always helped get my system unstable on 4-STABLE rather quickly.  I
think it was the issue of running two or more GL programs at the same
time that caused or increased the problem.

Are you using the latest nvidia drivers?


> The error this time was a double fault (are we playing tennis?).  My
> original issue was with a page fault in kernel mode.  And my original
> problem also was related to a different function.  The function this
> time is <scterm_puts+173>.

My panics were fairly random.

> Take a look at all those sig-11s.  I would suspect bad memory but I
> ran memtest86+ on this machine less than a week ago and everything was
> fine -- not even a whiff of a problem.  I caused this panic by running
> another gl application and I feel it is related to my orginal problem.

I also ran memtest86 for over a day without finding fault in the memory.
The sad thing is that almost any type of bad hardware can cause
stability issues.  At least this is what I was told.  Maybe the caps on
your system have started going bad?

> Another thing that interested me is that the kernel dump seems
> "corrupted" or incomplete... does the line "---Can't read userspace
> from dump, or kernel process---" possibly imply that I did not get a
> good dump at the time of the panic?
> If anyone has any ideas about what to fix I would love to hear them.
> I am tempted to change a few things myself that might be an issue (for
> example, removing the FreeBSD agp which nvidia complains about in my
> dmesg -- and also upgrading to  3-Beta1 ... so at least my kernel
> panics will relate to making that system better).  But, until I know
> that this is a dead end and no one wants to see anything, I am not
> touching anything.  I don't want to ruin the chances of this being a
> real bug and it not being fixed because I change something that just
> hides it.

You should not be mixing the FreeBSD AGP and the nvidia AGP together.
Choose one or the other.

> If you want me to get any information from the dump or try anything
> please let me know.  You may have to tell me how to go about doing
> stuff with gdb (I am not very experienced with its advanced features)
> but I am willing to learn and do what I can.

I have my own panic on 4-STABLE which I just reported in freebsd-stable:
Would you like to trade?  :)

sean-freebsd at farley.org

More information about the freebsd-current mailing list