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>