Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 23 Aug 2004 16:26:13 -0500 (CDT)
From:      Sean Farley <sean-freebsd@farley.org>
To:        Kevin Brunelle <kruptos@bellsouth.net>
Cc:        freebsd-current@freebsd.org
Subject:   Re: Fatal trap 12: page fault while in kernel mode
Message-ID:  <20040823161337.V715@thor.farley.org>
In-Reply-To: <1093293236.618.12.camel@fnord.quux.edu>
References:  <1093141197.643.28.camel@fnord.quux.edu> <1093188163.2100.4.camel@fnord.quux.edu> <1093293236.618.12.camel@fnord.quux.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

#!/usr/local/bin/zsh

# Try with and without.
export __GL_SINGLE_THREADED=1

/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
 	fi
done

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?

<snip>

> 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:
http://lists.freebsd.org/pipermail/freebsd-stable/2004-August/008530.html
Would you like to trade?  :)

Sean
-----------------------
sean-freebsd@farley.org



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040823161337.V715>