Infinity nf2 -agp problem
hi, i'm having some problems getting agp to work properly with my nf2
infinity. here's my setup
2600+ athlon xp-m
9700pro
450w psu
15k rpm seagate scsi disk
adaptec u160 controller
western digital 160gb ide drive
two opticals
corsair 512mb pc3200 c2 (tccd)
geil pc4400 (tccd)
and, of course, an nf2 ultra infinity
the system has been tried at stock and overclocked settings, both to
no avail. I have tried about 5 different bioses, catalyst drivers
between 3.1 and 5.6, and all but the very first release of the nforce
drivers. two video cards (one ati, one nvidia), two motherboards, no
scsi, a different psu, and different ram. still... agp problems.
here's what i've found out about the problem:
# the nvidia GART (agp) driver causes major instability/ boot failure
when installed. the standard microsoft pci to pci bridge must be used
for stability (yes, this means running the agp card effectively as a
66mhz pci card on its own bus)
with nvidia cards, this causes a loss of signal shortly after the xp logo shows
with ati cards, it also causes a loss of signal shortly after the xp
logo shows, however, I can avoid installing the gart driver from
nvidia, using the video card without any agp acceleration, then use
smartgart to enable agp writes. fastwrites are on in driver and bios,
verified with rivatuner. setting the agp 8x enable/disable in bios
does nothing. these blank screens are because "the device could not
complete a drawing operation"
when I try to force agp reads, it corrupts the screen shortly after
bootup, then after a restart, ALL accelerations are turned ON, with no
artifacting, but a crash happens within 30 seconds of bootup.
bottom line as far as I can tell: there is a system instability when
using the nvidia gart drivers because of a hardware-level deviation
from the agp standards. when teh bus is used at a lower transfer
rate, the requirements are loosened to the point where no instability
is caused. when the transfer rates are higher (normal agp 4x or 8x
with the agp bus locked to 66, 67, or 68mhz in bios), this deviation
from agp standards causes data corruption sent to and from the agp
card to the rest of the system, giving a blank or artifacted screen.
I know this because of the sheer amount of hardware tested, the number
of fresh xp installs, the different drivers and bioses used, and yet
persistent problems. Is this a known issue? if it helps, I have a
taiwan board and a china-made board, both with problems. I have
modified this board with a vdroop mod on the cpu voltage circuit, so
an rma probably wouldnt happen. the taiwan board was not modded, but
exhibited the same behavior, so its not the mod that caused it. if
you want screen shots of things, just let me know.
also, running the agp with agp reads disabled, I get about 3000
3dmarks lower than I should, in 3dmark01.
this problem has fixed itself on occasion, with many reboots. I just am tired of dealing wtih it... and it doesnt fix itself anymore... even after 3 hours of rebooting
after each failed boot to xp.
its not irqs either
hi, i'm having some problems getting agp to work properly with my nf2
infinity. here's my setup
2600+ athlon xp-m
9700pro
450w psu
15k rpm seagate scsi disk
adaptec u160 controller
western digital 160gb ide drive
two opticals
corsair 512mb pc3200 c2 (tccd)
geil pc4400 (tccd)
and, of course, an nf2 ultra infinity
the system has been tried at stock and overclocked settings, both to
no avail. I have tried about 5 different bioses, catalyst drivers
between 3.1 and 5.6, and all but the very first release of the nforce
drivers. two video cards (one ati, one nvidia), two motherboards, no
scsi, a different psu, and different ram. still... agp problems.
here's what i've found out about the problem:
# the nvidia GART (agp) driver causes major instability/ boot failure
when installed. the standard microsoft pci to pci bridge must be used
for stability (yes, this means running the agp card effectively as a
66mhz pci card on its own bus)
with nvidia cards, this causes a loss of signal shortly after the xp logo shows
with ati cards, it also causes a loss of signal shortly after the xp
logo shows, however, I can avoid installing the gart driver from
nvidia, using the video card without any agp acceleration, then use
smartgart to enable agp writes. fastwrites are on in driver and bios,
verified with rivatuner. setting the agp 8x enable/disable in bios
does nothing. these blank screens are because "the device could not
complete a drawing operation"
when I try to force agp reads, it corrupts the screen shortly after
bootup, then after a restart, ALL accelerations are turned ON, with no
artifacting, but a crash happens within 30 seconds of bootup.
bottom line as far as I can tell: there is a system instability when
using the nvidia gart drivers because of a hardware-level deviation
from the agp standards. when teh bus is used at a lower transfer
rate, the requirements are loosened to the point where no instability
is caused. when the transfer rates are higher (normal agp 4x or 8x
with the agp bus locked to 66, 67, or 68mhz in bios), this deviation
from agp standards causes data corruption sent to and from the agp
card to the rest of the system, giving a blank or artifacted screen.
I know this because of the sheer amount of hardware tested, the number
of fresh xp installs, the different drivers and bioses used, and yet
persistent problems. Is this a known issue? if it helps, I have a
taiwan board and a china-made board, both with problems. I have
modified this board with a vdroop mod on the cpu voltage circuit, so
an rma probably wouldnt happen. the taiwan board was not modded, but
exhibited the same behavior, so its not the mod that caused it. if
you want screen shots of things, just let me know.
also, running the agp with agp reads disabled, I get about 3000
3dmarks lower than I should, in 3dmark01.
this problem has fixed itself on occasion, with many reboots. I just am tired of dealing wtih it... and it doesnt fix itself anymore... even after 3 hours of rebooting
after each failed boot to xp.
its not irqs either
Facebook
Twitter