A7V133 and 686b bug.
Mark Behbehani
to shed light on the via 686b corruption bug. (It also gives me a
chance to vent).
I have had an Asus a7v133 board for almost 2 years now. It has been
as rock stable as any motherboard I have ever had _until_ I tried to
upgrade the hard drive. I started out with a MaxStor 53073U6 30 Gig
hard disk. When all of the press on the 686b bug came out, I dumped
my soundblaster live! and picked up a Turtle beach Santa Cruz instead.
Being the type that has to have a reliable system, uploaded the latest
4-in-1 and flashed the bios. I then thoroughly tested the machine by
copying huge files back and forth a half-dozen times and doing a CRC
compare. I encountered no problems. Feeling secure, I forgot all
about the problem.
Last February I bought a larger drive a western digital wd600bb 60Gig.
I used ghost to move the system from the maxtor to the wd and all was
well. I kept the maxtor in the system as a second drive. Last week
while trying to copy 4 Gig of files between the two partions on the wd
drive, the computer locked up and when I rebooted, the d: partition on
the 60 gig wd was gone!
After a few minutes of complete panic, I tried troubleshooting with a
win 98 boot disk (I have FAT32 on both partitions). Lo and behold, d:
was there, but if I booted to win2000, it was gone. I decided that
before I did anything I would back up the system using ghost. (If you
have ever backed up 60 gig to CD-R, it takes a looonnnggg time). With
my data backed up I started looking at scandisk on d:. Scandisk found
a missing media byte and a damaged fat and It repaired it from the
backup fat. Boot to 2000 and everything was good.
Fast forward one week. I am watching a movie while kazaa is sharing a
large chumk of files. System locks up. Reboot to windows 2000 and d:
is missing again (this is getting old). Win98 boot floppy shows d:
there but in 2000 d: is missing. Scandisk finds nothing wrong. At
this point I suspect the drive. I get a brand new 100Gig wd1000jb to
backup all my data from the 60 gig.
At this point I have a couple of options I have a copy of lost and
found that has saved me in the past, but I end up getting ahold of
media tools by ACR data recovery. In 3 hours media tools has repaired
my disk and has me up and running of the 60gig C drive with c and d
backed up to the 100gig. All looks well and good.
When I try to run a couple of files from the copy of d on the 100 gig
they run fine, so I start copying. Lockup instantly. D: gone on 100
gig. Repair. Try to copy again, same thing. After some
experimentation I discover that the 100 gig wd cant copy more than
about 100 megs at a time without freezing the system and corrupting
the partition on the reading drive. Worse yet the directory that I
was trying to copy when the lockup occurs is gone (I mean gone gone
nothing can find it).
With backups on hand I decide to experiment. I can read, write, boot,
and copy large chunks of files on the 30 gig no problems. On the 60
gig I can copy up to about 2 gigs without a problem. On the 100 gig I
can copy about 100 megs before the drive gets trashed. It was later
determined that all the drives are perfectly functional and data that
was not accesed (backed up c: partition) was perfectly intact.
This is obviously the 686b bug rearing its ugly head. With a slower
hard disk (30 gig maxtor) the system performs perfectly. With a
faster hard drive(60 gig wd) the system can do everthing up to copying
gigs at a time. With the very fast 100gig wd the system is just about
unusable. The problems were slightly worse on the onboard promise
controller (it is ata100 vs ata66 for the via ide). It seems the
problems appear when the PCI bus on the MB (or 686b or the link to
northbridge) saturates. One file is not enough, but if you send
enough data fast enough, it just starts sending random commands to the
IDE (such as write #FFFFFFFFh to the boot sector).
In short if you have an a7v133 be VERY cautious about upgrading to a
faster drive. I ended up upgrading the MB to an KT333 MSI kt3 ultra2
which has no problems with any of the drives. I performed an in place
reinstall of 2000 on the 100 gig and backed up the d: from the CD-Rs.
I hope my saga can prevent this from happening to someone else.
Thanks,
Mark Behbehani
Paul
coinst...@hotmail.com (Mark Behbehani) wrote:
The first web page I found was:
http://www.amdmb.com/files.php
In principle, this should be fixed by the Via 4-in-1 drivers.
At the very bottom of the above web page, it says:
Via 4-in1 v. 4.31, fix for the Via 686B bug
So, make sure you have installed a recent version of these
drivers, before trying anything else. If you still have
trouble, on the same page it says:
KT7 686B Beta Bios:
Quote from VIAHardware: "Beta BIOS for KT7A and KT7A-RAID that
changes the following three register valus to be "0":
-PCI Delay Transaction = 0
-PCI mast Read Caching = 0
-PCI Latency = 0
As a potential solution for the large data transfer corruptions
on the KT133A chipset."
so the problem is influenced by the BIOS setting of Delayed Transaction
and PCI Latency. Using a sacrificial disk drive, I would start by
disabling Delayed Transaction (which should cause your sound card
to start stuttering...), then do a large transfer. Reducing PCI Latency
is fine, up to a point, but on the box I was fighting with, things
slowed to a crawl with lower settings (desktop was slow to update etc).
Another way (which sucks) for fixing this, MIGHT be to use one of those
drive manufacturer utilities that slows down the interface on the
disk drive. The program writes a field in the disk drives controller
board, that changes the drive from ATA133 to ATA100, ATA66, ATA33 and
so on. I seem to remember some other web site saying that
drive performance was one ingredient of the bug.
Other articles:
http://www.sudhian.com/showdocs.cfm?aid=29
http://www.tecchannel.de/hardware/817/1.html
http://www.georgebreese.com/net/software/readmes/faqvl019.htm
HTH,
Paul
Egil Solberg
> unusable. The problems were slightly worse on the onboard promise
> controller (it is ata100 vs ata66 for the via ide). It seems the
> problems appear when the PCI bus on the MB (or 686b or the link to
> northbridge) saturates.
The 686B supports ATA100. Or do you indeed have an A7V with the 686A
southbridge?
Joe Doupnik
> In article <36ce3efa.03020...@posting.google.com>,
> coinst...@hotmail.com (Mark Behbehani) wrote:
>
>> This post is a little long, but I hope that this post will be useful
>> to shed light on the via 686b corruption bug. (It also gives me a
>> chance to vent).
Been there, experienced the same phenomenon. I worked around it
by installing George Breeze' PCI Latency patch into Win2K and XP. It
works, but it is not perfect. Look round for it, say on amdmb.com or
Google.com.
My ultimate cure was like yours: go to the KT333/400 newer
motherboards where the problem is absent. In my case it was to Gigabyte
rather than to ASUS. All my A7V133 motherboards exhibited the problem to
greater or lesser degree; I don't run Windows on all of these machines.
Joe D.
Mark Behbehani
Sorry my mistake. It is definetely a a7v133 with the 686b
southbridge. I have the pci latency patch from via. I didnt mess
around with crippling the system further than that. Now that I have
the KT333 I dont have to worry about it, but I did pass the info to my
roomate, who inherited the a7v133
Thanks,
mark