- Apr 10, 2001
- 2,370
- 0
- 19,780
Okay, I was just messing around, looking up helpful articles. I stumbled across <A HREF="http://www.tech-report.com/news_reply.x/2448" target="_new">this one</A>. But, the important one I read was #44 (You'll know what I mean...)
Here it is if you don't want to click that link. It wasn't me, so I'm not to be given credit:
~~~~~~~~~~~~~~~~~~~~~~~~
44. Posted by Dr. John
at 09:56 pm
on May 11th 2001
x It has been our contention for some time, based on our experience building Athlon computers that have to work right, that the VIA bug is real, and they have basically adimitted the fact, with the stipulation that Creative was a contributing factor. This is the standard take on the problem as picked up off of one of VIA's boards:
______________________
VIA has confirmed a data-damaging glitch in its 686B southbridge chip - a major part of the Taiwanese company's KX133 and KT133A chipsets - and is working with mobo makers to prepare BIOS updates to fix the problem.
The bug was uncovered by German hardware site Au-Ja! It's not exactly a common problem: the data corruption affects large, 100MB and up file transfers between two ATA-100 hard drives exchanging the data by DMA. Having a Creative Labs Soundblaster Live card in place seems to exacerbate the problem.
VIA's BIOS fix works by adjusting a number of PCI settings, which, according to TechChannel, suggests the problem is a result of competitive PCI access.
■ Set PCI Delay Transaction to off
■ Set PCI Master Read Caching to off
■ Ensure the PCI Latency <= 32
If your BIOS supports it, you can change the options there, otherwise there are some VIA tools that can set the registers on the 686B to achieve the same effect.
Presumably the VIA patch that's to be released will do all this automatically.
The original English article is here:
http://www.au-ja.de/review-kt133a-1-en.html
____________________________
These guys explain it in plain terms fairly well.
From my readings, I remember VIA as the one who said that the problem occurred when there was "excessive traffic on the PCI bus". I think there may be two issues here, and you all may be able to clarify the situation. The first is DMA access. We found a long time back that disabling the "DOS SB 16 emulation" for the Live series reduced the problems, but often did not eliminate them completely. The SB16 emulation feature takes up two DMA channels, along with an IRQ. The SB Live also seems to exhibit occasional problems when certain CD/DVD/CDRW drives have DMA access enabled. Something seems wrong with the way the SB Live emulation crap uses DMA channels.
The next issue is the 686B southbridge/PCI bus issue itself. I'm not sure how the two interact, but they do, and end up creating a much bigger problem than you'd see otherwise. So yes, the bug is there, it has to do with DMA-enabled drive access, and anything that exacerbates the traffic collisions in the southbridge and associated bus makes the problem much worse. Creative and VIA were both sloppy, and together thay can crash and burn.
Epiloge:
VIA makes cheaper products on a comparatively shoe-string budget (although that's changing). Our busines has been able to stay afloat on AMD/VIA sales.... we would have died if we had tried to pull a Dell-like Intel-only thing. VIA gets a very positive rating from us because they got to "near-Intel-quality" pretty quickly, and they are helping kick Intel in it's lazy butt. We can sell fast, reliable Athlon systems very inexpensively because of these two, much smaller companies, and that wouldn't be true if we were trying to sell P4 systems.
Note that when we set up Athlon systems (KT7A-RAID, A7V133) we follow these critical rules:
Keep each IDE device on their own controller. Put the hard drives on the RAID controllers (Highpoint or Promise), and put the CD/DVD/CDRW drives on the ATA/100 controllers. Do this, and disable SB16 emulation, and you won't have any problems (at least we don't). This limits you to 4 IDE devices.
U160 SCSI drives would also obviate these problems (my favorite solution).
I wish VIA would grow up and publish everything, from all technical specs to all known errata, but they are a Taiwanese company, so don't expect them to act like a big US company any time soon.
Over time, VIA chipsets will get even better.
doc
~~~~~~~~~~~~~~~~~~~~~~~
Perhaps we can try changing these settings in our BIOS. But, I don't know how to test them out. If someone can know how to do so...ya know... Those settings mentioned in that post are in the BIOS for the A7V133, though. That's the motherboard I have. My hard drive is in the ATA100 slot, though, so I'm not sure if it affects me.
Anyways, can we all just figure out what to do until VIA comes out with a frickin fix? (Don't worry...it bugs me too that we, the consumer, have to figure out fixes instead of the company.
)
<i>OC...unless your computer's cheezy (is that a good rhyme?)</i>
Here it is if you don't want to click that link. It wasn't me, so I'm not to be given credit:
~~~~~~~~~~~~~~~~~~~~~~~~
44. Posted by Dr. John
at 09:56 pm
on May 11th 2001
x It has been our contention for some time, based on our experience building Athlon computers that have to work right, that the VIA bug is real, and they have basically adimitted the fact, with the stipulation that Creative was a contributing factor. This is the standard take on the problem as picked up off of one of VIA's boards:
______________________
VIA has confirmed a data-damaging glitch in its 686B southbridge chip - a major part of the Taiwanese company's KX133 and KT133A chipsets - and is working with mobo makers to prepare BIOS updates to fix the problem.
The bug was uncovered by German hardware site Au-Ja! It's not exactly a common problem: the data corruption affects large, 100MB and up file transfers between two ATA-100 hard drives exchanging the data by DMA. Having a Creative Labs Soundblaster Live card in place seems to exacerbate the problem.
VIA's BIOS fix works by adjusting a number of PCI settings, which, according to TechChannel, suggests the problem is a result of competitive PCI access.
■ Set PCI Delay Transaction to off
■ Set PCI Master Read Caching to off
■ Ensure the PCI Latency <= 32
If your BIOS supports it, you can change the options there, otherwise there are some VIA tools that can set the registers on the 686B to achieve the same effect.
Presumably the VIA patch that's to be released will do all this automatically.
The original English article is here:
http://www.au-ja.de/review-kt133a-1-en.html
____________________________
These guys explain it in plain terms fairly well.
From my readings, I remember VIA as the one who said that the problem occurred when there was "excessive traffic on the PCI bus". I think there may be two issues here, and you all may be able to clarify the situation. The first is DMA access. We found a long time back that disabling the "DOS SB 16 emulation" for the Live series reduced the problems, but often did not eliminate them completely. The SB16 emulation feature takes up two DMA channels, along with an IRQ. The SB Live also seems to exhibit occasional problems when certain CD/DVD/CDRW drives have DMA access enabled. Something seems wrong with the way the SB Live emulation crap uses DMA channels.
The next issue is the 686B southbridge/PCI bus issue itself. I'm not sure how the two interact, but they do, and end up creating a much bigger problem than you'd see otherwise. So yes, the bug is there, it has to do with DMA-enabled drive access, and anything that exacerbates the traffic collisions in the southbridge and associated bus makes the problem much worse. Creative and VIA were both sloppy, and together thay can crash and burn.
Epiloge:
VIA makes cheaper products on a comparatively shoe-string budget (although that's changing). Our busines has been able to stay afloat on AMD/VIA sales.... we would have died if we had tried to pull a Dell-like Intel-only thing. VIA gets a very positive rating from us because they got to "near-Intel-quality" pretty quickly, and they are helping kick Intel in it's lazy butt. We can sell fast, reliable Athlon systems very inexpensively because of these two, much smaller companies, and that wouldn't be true if we were trying to sell P4 systems.
Note that when we set up Athlon systems (KT7A-RAID, A7V133) we follow these critical rules:
Keep each IDE device on their own controller. Put the hard drives on the RAID controllers (Highpoint or Promise), and put the CD/DVD/CDRW drives on the ATA/100 controllers. Do this, and disable SB16 emulation, and you won't have any problems (at least we don't). This limits you to 4 IDE devices.
U160 SCSI drives would also obviate these problems (my favorite solution).
I wish VIA would grow up and publish everything, from all technical specs to all known errata, but they are a Taiwanese company, so don't expect them to act like a big US company any time soon.
Over time, VIA chipsets will get even better.
doc
~~~~~~~~~~~~~~~~~~~~~~~
Perhaps we can try changing these settings in our BIOS. But, I don't know how to test them out. If someone can know how to do so...ya know... Those settings mentioned in that post are in the BIOS for the A7V133, though. That's the motherboard I have. My hard drive is in the ATA100 slot, though, so I'm not sure if it affects me.
Anyways, can we all just figure out what to do until VIA comes out with a frickin fix? (Don't worry...it bugs me too that we, the consumer, have to figure out fixes instead of the company.
)<i>OC...unless your computer's cheezy (is that a good rhyme?)</i>
Facebook
Twitter
Instagram