HP Pavillion 3700+
Prod #: t3245.uk
Here's my problems with it and my big list of workarounds, none of which nvidia corp. will recommend!
My assessment of the nVidia 6200SE TurboCache shows that the card automatically changes clock speeds when it enters Xorg and when fullscreen games start. This change of speed can result in a fast heat up of the card, around the 68-78C range games are several times more likely to cause a kernel panic, Xorg with only 2D apps is about twice as likely to cause a kernel panic. The heat-up only appears to occur when running OpenGL games or using applications requiring heavy use of Direct Rendered 3D Acceleration.
So a temporary workaround that nvidia might be able to implement in their drivers if possible is to lower the slowdown threshold which is currently at 145C on the 6200SE TurboCache or offer a way to adjust the threshold on their "NVIDIA X Server Settings" application.
For users a set of ways to lessen the load and make the system more stable while using OpenGL 3D applications:
There is an unofficial nvclock application that can show the clock speed of nvidia cards, the latest version (0.8 at this time of writing) is capable of adjusting the clock speed. After loading a fullscreen OpenGL game and after Xorg has loaded nvclock can be used to lower the clock speed thus reducing the level of heat and lessening load on the card. Unfortunately nvclock cant currently change the 6200SE TurboCache's fan speed which would effectively help lessen heat slightly. Instead users should attempt to add extra cooling to the computer in general to lessen heat generally which will lessen stress on the card thus reducing the likelyhood of a crash.
For gaming, running a minimalist distribution such as Gentoo and implementing the above strategies is incredibly effective at reducing hard lock-ups and kernel panics, infact at low temperatures in the 50-55C range very few panics/lock-ups have occurred with the current drivers (1.0-9631 at this time of writing).
For normal PC usage, using a distribution such as Red Hat Enterprise Linux or CentOS and implementing the above will dramatically lower the chance of a crash, so far at this time NO lockups/panics have occurred with the current drivers (1.0-9631 at this time of writing) under standard usage after implementing the above. The system successfully runs CentOS x86_64 with an average uptime of 3 days with common usage (IRC, IM, Web Browsing etc.).
Using FreeBSD 6.1-RELEASE. VERY frequent lock-ups, likely to be kernel panics. Not limited to the use of 3D Direct Rendering or OpenGL. The frequency of the lock-ups suggests that older versions of nvidia drivers and those on slightly less used systems are much less stable. An average uptime of 1 hour between lock-ups without following the above and an average of 8 hours with following the above suggests driver stability is to blame.
Using Windows XP Home Edition Service Pack 2 and Windows Server 2003 Enterprise R2. NO crashes of any kind have occurred even under VERY HIGH load, this demonstrates that drivers under Windows maintain stability. This could however be down to the Windows Microkernel which has over time developed a level of internal resistance to kernel-level crashes due to 3rd party drivers.
In conclusion one can easily tell that the nvidia drivers under Linux and FreeBSD lose stability under high load and/or when the 6200SE TurboCache becomes hot, stability can be greatly enhanced by lessening load on the graphics card and implementing extra cooling to prevent the graphics card from reaching temperatures exceeding 65C which is the threshold for which the current Linux drivers (1.0-9631) appear to start causing kernel panics and hard lock-ups.
GNU/Linux distributions tested:
Fedora Core 5 (x86_64) (with some modifications)
Gentoo Linux (x86_64)
Gentoo Linux (i386)
Other Systems Tested:
Windows XP Home Edition Service Pack 2 (x86)
Windows Server 2003 Enterprise R2 (x86)
FreeBSD 6.1-RELEASE (i386)
This is my detailed end-user report on the issue, I expect this FIXED. I will keep an update on the CentOS x86_64 under normal use to inform of any crashes. I am posting this report using this system ;-)
On older nvidia drivers the monitor appears to go into a form of suspend mode upon a crash, on the current Linux drivers that has yet to happen. This may suggest that some problem has already been fixed.