Data corruption on A7V133

Hi all!

I recently bought an Asus A7V133 with VIA's KT133A chipset, and I have a "little" problem with it. As soon as I enable DMA for my hard disks, data gets corrupted on about 75% file transfers I do. Same thing happens when I put my HDs in the ATA/100 controller. I tried a few HDs, so I doubt this is the problem. Here are my specs, if they can help you find a solution:

Asus A7V133
AMD Duron 800
128mb RAM PC100
AOpen AW744 PCI Sound card
3DFX Voodoo5 5500
AOpen AON-315 Network Card
PS/2 Mouse & Keyboard
Asus 50X CD-ROM
250W Power supply
And my current HD is a WDC 205AA, but I tried more recent ones.

Oh, and I'm using the latest BIOS available, and installing VIA's 4-in-1 drivers didn't help.

Any help is greatly appreciated. Thanks a lot!

<P ID="edit"><FONT SIZE=-1><EM>Edited by barry_gibb on 05/05/01 08:09 PM.</EM></FONT></P>
23 answers Last reply
More about data corruption a7v133
  1. Go to to your motherboard mfg's website and download the latest bios update.

    96.3 % of Statistics are made up.
  2. Go to Via Germany's website, You'll find that they recognize a problem with the new 686B southbridge. I don't believe there's a fix yet.
  3. Yeah, I heard about that problem in Tom's tech news on April 13th, but, as you said, I don't think there's a fix yet. I guess I'll have to wait.

  4. Are you overclocked?
  5. Interesting. Exactly what do you do to get the failure? Like, transferring data from where to where, and under what conditions (e.g. DMA settings of the devices, sound card playing music)?
  6. My CPU isn't overclocked, and no other program is running.

    My "favorite" test is extracting a RAR archive with WinRAR, because it reports errors as soon as they happen. And no, my archive isn't corrupted, because it extracts OK when I'm not in DMA mode. I tried extracting from a CDROM or from another hard disk to my primary one, but results aren't better.

    Also, I tried all DMA modes possible using VIA's IDETool, and they were all unsucessful.

    Oh, and I'm using Windows 98 Second Edition. Maybe I should try WinMe?

    Thanks again!

    <P ID="edit"><FONT SIZE=-1><EM>Edited by barry_gibb on 05/06/01 03:30 PM.</EM></FONT></P>
  7. Swapping to ME won't do crap, probably make things worse, then you'll be reformattin to get rid of it completely
  8. When I overclock too far, I get corruption too. If you're aircooling, and you're not overclocked, you should be able to get good transfers up to a little over 60C. If you're overclocked at all (~50mhz), you need to keep your temps at or below 45C aircooled.
  9. As posted on <A HREF="" target="_new">April 13th for Tom's Tech News</A>:
    "VIA Technologies is preparing BIOS updates with motherboard manufacturers for a rare data-corrupting problem in its 686B Southbridge chip, part of the company's KT-133A chipset. The bug only affects file transfers of files of 100MB or larger between two hard drives connected to separate IDE channels exchanging the data by DMA. The fix will be posted, according to the Register, on VIA's Website next week."

    I used Partiton Magic to rearrange my partitions, and all the data on the ones being moved were corrupted. After running scandisk, with the Lost File Fragments option to "Convert to files", they were all converted to .chk files. (Major ouch :frown: ...luckily they were backed up. :smile: )

    The article says that it's for transfers between <b>two</b> hard drives over 100MB though. I only have one IBM 75GXP Deskstar 30GB hard drive. But, Partition Magic was working under DOS. So, it's probably due to the screwed up BIOS (at least those are my thoughts after reading a little for this thread). My hard drive was set in the ATA100 slot before this happened. Then again, I haven't use Partition Magic in awhile to do what I did.

    Does unchecking DMA "fix" this problem until an actual fix shows up?

    <i>OC...unless your computer's cheezy (is that a good rhyme?)</i> :eek:
  10. I don't think it has something to do with the CPU temperature, since, as btvillarin thought, unchecking DMA "fixes" the problem.

    Maybe Partition Magic could help. I'll try that as soon as I can make a backup.

    And about the BIOS... I already tried that twice, but maybe I'll get lucky on the third time, it's worth trying.

    Thanks again everyone, your help is greatly appreciated!
  11. I wasn't saying that Partition Magic would help against data corruption. What I did was merge a couple of my partitions together. They consisted of mp3s (a <b>lot</b> of mp3s), a <b>lot</b> of download programs, and my documents. After the merge, I ran scandisk then checked out my new partitions. All my data were .chk files. I'm not sure what Partition Magic has to do with Windows, though. Plus, on my old computer, that never happened when I merged partitions together. But, it did involve transfers <b><i>over 100MB</i></b>. So, that might be the key. I can't do any big transfers like that for awhile.

    So, backup like crazy every week, maybe you'll even go out and buy Drive Image & Partition Magic...they are well worth it. Plus, having a CD burner saved me because I now have backups available in case my tinkering goes haywire.

    As for the BIOS, I just set all the default to make sure everything was correct. But, maybe the BIOS needs and update or something. That's all I was saying.

    The CPU temp doesn't aid in corrupting data, though. My partition "escapade" was around 6:30pm (Southern California), and I have a Compunurse right next to the core. It was showing about 48°C. I've gotten higher than that, and there was never any data corruption. So, that can't be it.

    I don't know if I stated this, but the data corruption <i>for me</i> occurred after I changed my hard drive IDE connector from the Primary IDE Connector to the Primary ATA100 slot. Plus, before that, DMA was also checked in Windows and I was running fine.

    Okay, so I guess I'm saying that if your HD is in the ATA100 slot, move it back to the Primary IDE slot. Then, if you have an ATA100 hard drive, in the BIOS, bump the UDMA to 5 (page 57 of the Asus A7V133 User's Manual revision 1.02 E704).

    (If this helps you, please let me know...)

    <i>OC...unless your computer's cheezy (is that a good rhyme?)</i> :eek:
  12. Here's the <A HREF="" target="_new">original news article</A> from The Register. Maybe if we all email the writer of this article, <A HREF="" target="_new">Tony Smith</A>, he can help dig into this. If you note the date, it was posted on April 12, 2000. Now, it's May 7th. I'll bet a lot of people aren't aware of this problem. Then, when they transfer some humongous files, like I did (even though I got lucky), they get screwed.

    So, what do you all think?

    <i>OC...unless your computer's cheezy (is that a good rhyme?)</i> :eek:
  13. I have to agree that (a) it's unlikely to be a temp problem, and (b) ME won't make any difference.

    You might have the infamous 686B bug. There's a lot of disinformation about that one out on the web, VIA is claiming it only occurs with the SBLive, the German site that reported it claims they can reproduce it without the SB Live. The bit about 100M transfers isn't quite right, either; the Germans transferred very large amounts of data by transferring a large file over and over again to produce the failure. The transfer was done between ATA devices on separate IDE channels. They probably used a large file to make sure the streams ran continuously for long enough, and to make sure they were really transferring to/from the devices (rather than hitting an image cached in memory). It might be more accurate to describe the failure in terms of a failure rate per byte transferred when bulk (continuous) transfers are being done. The failure rate dropped (but not to zero) when removing the SB Live.

    Thing is, you don't have an SB Live, you're not (as far as I can tell) transferring large blocks of data between UDMA drives on separate IDE channels, and it sounds like you encounter errors with far greater frequency.

    When you do these archive extractions, are you effectively reading a ton of data from a large file and writting it out to disk? If so, does it make a difference if this is done on the same disk, or across different disks? If across disks, what about switching the DMA on/off in different combinations between the "reading" disk and the "writing" disk? If on a single disk, does this mean you can get a failure by doing a read-only test on the file (like a checksum)? Finally, can I assume the file is large enough to ensure that it's not been cached in memory by Windows?

    <P ID="edit"><FONT SIZE=-1><EM>Edited by dmcmahon on 05/07/01 04:05 PM.</EM></FONT></P>
  14. :eek: Great, <b>I</b> have a Soundblaster Live! sound's over!

    <i>OC...unless your computer's cheezy (is that a good rhyme?)</i> :eek:
  15. btvillarin: yeah, it might be a good idea to email someone about this. The article's author might be a good suggestion, but I feel that we should also let VIA know about it. Well, they know it, but they think it's only under certain conditions, which I think is not true.

    dmcmahon: I tried transferring large and small files, but with the same result, and in both cases 1 to 3 errors occured during a ~400mb transfer. It does the same when I do it on the same disk or accross different disks. Also, I think it reads data wrong: when DMA is enabled and I try to play Counter-Strike on the net, it says that some file must not be corrupted in order to play on that server. I don't have that problem without DMA.

    Once again, thank you everyone!
  16. Incredible. In theory, then, you could run a checksum over and over again on a large file and different results each time. Have you tried this? It would prove that you have a (heretofore) unique problem that does not involve transfers between devices. As I dimly understand it the 686B bug is a result of confusion when multiple DMA operations are in progress at onces. This should not be the case with a single device (unless you're playing MP3s at the same time?).
  17. Your problem is unique and is not enirely related to the 686b chipset bug. The fact that you encounter errors tranfering files across the same disk is one of the first of this nature I have heard of. What Os are you running? Have you checked your cables? Last but not least I see you are running pc-100 memory, can I ask why?

    A little bit of knowledge is a dangerous thing!
  18. dmcmahon: I'm not familiar with checksum things. How could I test that? And no, I don't run MP3s when I test.

    Ncogneto: I'm running Win98SE, I checked my cables at least a thousand times, and about the memory, it's because that's the same memory I had when my CPU was a celery. And since the Duron's FSB is 100 (or 200, whatever) and I don't plan to overclock it soon, I didn't feel the need to upgrade to PC-133.

    That's a good point though, I should try with PC-133 memory. Another thing I thought of is the power supply. Is 250W enough? I know that the Voodoo5 takes a lot of juice, so might it be a problem?

  19. i am getting data coruption in file transfers of as little as 1.2 meg to floppy when backing up an accounting program, i think this mobo has be given back to the shop,...and unfortunately...i may have to go Intel /pentium ....
  20. Everything I've read suggests that 250W is probably inadequate, and that 300W is recommended. However, this is unlikely to be the source of your problem because the amount of power used by the system is unaffected by the DMA mode setting.

    You can download a very simple checksum program from, look for off of that page. The source code is included if you're worried about viruses (I wrote this program myself because Windows didn't see fit to supply such a utility). Basically all it does is read every block from a file and run CRC-32 on them, in sequence. The result is then printed to the command window as an 8-digit (32-bit) hexadecimal number, followed by the number of bytes read from the file. The odds that two different files will have the same CRC32 + size values are 1 in 4 billion. So, if you do a CRC on a file with known "good" reads (i.e. DMA is off in your case), you can then copy the file elsewhere and rerun the checksum to see if it's still the same or not. If, as you seem to suggest, there is a problem reading even from a single device with DMA on, then in theory this problem would affect the checksum program itself, cause it to give a different value for CRC32 every time you run it (because it will get incorrect data every so often to randomize the result). Might help get some insight into the problem, might not.

    I'd be interested in the results if you try this in various scenarios, i.e. try it with DMA off, copy the file, run it again on the copy, then switch DMA on, run it again on the original file (in fact run it several times to see if you get different results each time), make another copy, then run it another time on this new copy.
  21. You guys scared me already! Since DDR takes too long, I was gonna purchase a A7V133, but I see you guys have a lot of problem with it. Should I go for it or not? Please give me some suggestions and alternatives! I will be thankful! =)
  22. I am not having any problems with my A7V133. I had a lot of problems initially, due to a combination of problems with the software, and while trying to solve those problems (all of which are now resolved) I got into these web forums and found out about other problems that scare me a bit, like the SBLive/686B data corruption problem. I am disappointed at the number of patches and work-arounds I was required to install to get my system running, but, it works. You can get this board and a CPU very cheap now because DDR is here. Not sure DDR with AMD is going to be more stable; several of the issues I ran into were specific to the Athlon, and so a different board wouldn't help. The data corruption issue appears linked to the VIA 686B south bridge, which is also used on most of the DDR boards. Because stability is the most important criteria for me, if I had it to do over again I would buy an Intel 815 motherboard manufactured by Intel, accept the 512M memory limitation and the lower CPU speed attainable. It really sucks right now because Intel won't have a DDR chipset for at least a year thanks to their deadly embrace of Rambus, and AMD seems to lack a really robust chipset. Good luck whatever you decide. If you do get this board check out the web sites linked off of my a7v133.htm page to make sure you have all necessary software patches.
  23. Thanks dmcmahon, I'll try that out as soon as I can and post the results here.
Ask a new question

Read More

Motherboards Asus