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
-----------------------
[EMAIL PROTECTED]
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
