ruthlezz_1 said:
What can I do to troubleshoot drivers?
When I had an ATI video card, the drivers that came on the CD in the box,
caused the computer to crash just when the desktop was about to appear.
The solution was to get the latest driver, downloaded right from the ATI
web site. On average, for each new video card I buy, I test three different
drivers and pick the best of the lot.
http://ati.amd.com/support/driver.html (select Radeon, then 9250 from the list)
There are even older versions available:
http://ati.amd.com/support/drivers/xp/radeonx-prer300-previous-xp.html
When the ATI driver is installed, and you go to the Display Control
Panel, you'll find a "SmartGART" tab. That tab has some options for
setting up the graphics card. You can set the AGP transfer rate
there. If an AGP 8X setting is not stable, that panel will offer
options to test a slower rate, like 4X or 2X. The change in the transfer
rate is tested and applied, the next time the computer boots, just as the
Windows desktop is about to appear. You have to open the SmartGART tab
again, to see whether the settings "took" or not. If the SmartGART
software tests the video card at the requested new rate, and the
card doesn't like the new settings, the settings will revert to
some other value. SmartGART can be super-annoying when you're trying
to test stuff. Control from the BIOS was a lot more straight forward.
Freezing problems are hard to debug. One case was caused by a bad
Marvell network driver. Bad RAM really shouldn't do it, and you'd
expect a BSOD or a program crash with bad RAM, or even a corrupted
registry. Other reasons for hardware to freeze, is when bus arbitration
fails, and a bus is deadlocked and cannot recover. But in modern systems,
there should be recovery mechanisms for stuff like that. At one time,
a double-bus-fault (two failures to read RAM in a row), would cause the
processor to stop executing, but again, I don't know if that protocol
is still in effect or not.
I just finished debugging a freezing problem on the 440BX chipset, and
my conclusion there was, it was an actual design problem with the 440BX.
In that case, I tested with memtest86+ and with Prime95. Both tests passed,
and I did Prime95 overnight twice, just to be sure. If 4x256MB of RAM
was present, the system would freeze, even doing 2D video stuff. It
didn't even need any 3D to freeze. The clincher for me, was when it froze
in several different OSes. At one time, I had figured the problem was
just with Win98SE, but in fact Linux distros had just as much trouble.
The solution was to run with 2x256MB of memory, and the system is now
able to do as much 3D as I want, in any OS I want. I don't expect
you'll find the same problem with Nforce2, as it is miles ahead of the
chipset I just finished debugging. What you can learn from this
paragraph, is using an alternate OS is useful for determining whether
drivers could be a contributor - if the hardware is just as flaky,
while using something like Linux (Knoppix, Ubuntu, the "live CDs") or
one of the other UNIXes like FreeBSD, then you'd suspect a hardware
problem of some sort.
Paul
