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.
#!/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 at farley.org
More information about the freebsd-hackers
mailing list