Ga naar de Google Groepen homepage
Discussiegroepen
  
Het Internet    Afbeeldingen    Discussiegroepen    Gids    
  Geavanceerd zoeken in groepen
  Voorkeuren    
 Discussiegroepen Viewing message <4ccodtc4tjlgdg8e3pclqf1j39cnruhhlh@4ax.com> 
 Free PCI-X Whitepaper • Extend the life of your design Upgrade from PCI to PCI-X • www.tundra.comGesponsorde Koppelingen 
Van:Anthony Hill (hilla@uoguelph.ca)
Onderwerp:VIA PCI/data corruption follow-up
View: Complete Thread (5 bijdragen)
Original Format
Discussies:comp.sys.ibm.pc.hardware.chips
Datum:2001-04-17 05:50:01 PST
Hello all

I've done a bit of looking around into the recently publicized
problems with VIA chipsets and data corruption, among other things.
First off, I'd like to point people looking for more info to the VIA
Hardware page at www.viahardware.com, and especially to their Forums,
which is where most of this info has been gathered from.  Anyway, on
to the meat of things..


First off, VIA chipsets DO appear to have some problems, but to the
best of what I can tell, it does not entirely have to do with their
hard drive controller as originally reported, that's more a symptom
that the cause.  The main problem with the VIA chipsets seems to be
some issues with PCI bus arbitration.  In particular, if there are
more then one PCI bus mastering devices fighting over the bus (almost
always requires at least 3 PCI devices), it seems that occasionally
one or the other PCI devices will run into problems.  As best as I can
tell (though I'm just taking an educated guess here), the problem is
that the bus arbitrator starts by telling the first PCI device to take
the bus, then tells it to stop using the bus before it passes
controller to the next PCI bus master.  However, it seems like the
second PCI bus master is given control before the first bus master has
finished putting data onto the bus.  End result, for a brief instant
you have two PCI devices reading/writting to the bus at the same time.
As a side note, the problem does seem to occur under both Win2K/NT and
Win9x.  No reports of problems under Linux, though the sample size of
Linux users has thus far been pretty small.

Now, the next issue is with the Creative Labs SBLive!  The problem
here seems to be a rather crappy set of drivers with a poor PCI
implementation (among other problems discovered with this card).  The
SBLive! seems to generally screw up PCI buses, and in fact has
resulted in a number of very similar problems with AMD, ALi and even
Intel chipsets.  Problems are most pronounced though when combined
with a VIA chipset.  I should also point out that the SBLive! is not
the only sound card that causes these problems.  In fact, most
Creative problems seem to cause similar problems, as well as Aureal
Vortex cards (Creative did buy out Aureal, though I believe that this
is just coincidence).  Basically to a one, all users that reported any
problems with things when using an SBLive found that they disappeared
when switching to sound cards that haven't been touched by Creative
Labs hands (the Turtle Beech Santa Cruz seems to be the number-one
pick as a replacement).


Now, just what are the problems that people ran into.  Well, by FAR
the most common is simply crackling from the sound card when certain
other devices are accessing the bus.  I personally ran into this one
on my system.  Problems with data corruption do also seem to occur,
though far less frequently, however such problems are not limited to
the KT133A/686B combo, but also occur with a number of other VIA north
and south bridges (for both AMD and Intel processors).  The exact same
problem also seems to happen with at least one model of Promise IDE
controller chip.  On the more extreme side of things, quite a few
people also reported some system crashes, some while copying large
quantities of data, others while watching movies.  Interestingly
enough, I have run into some rather odd crashes while watching movies
that sound very similar to what others have mentioned, though
previously I had figured that they were probably caused by a stick of
memory which is known to not be 100% reliable.  When it comes to
problems with Creative products on Intel chipsets, the incidence seem
a fair bit less common, but they do exist none the less.  Problems
mostly seem to be sound crackling when other PCI bus mastering devices
are working, data corruption when using a Promise controller (I
haven't yet seen a report of data corruption with an Intel
southbridge, though the response I've seen are, admittedly limited),
and even the odd crash.  These problems have been reported on LX, ZX,
BX and i815 based boards.


Now, as for the true nature of this problem, it's somewhat unclear if
it's just a matter of an actual bug in the VIA chipset, simply the
BIOS parameters cutting things just a little too tight for the spec,
or the PCI devices exceeding the limits of the spec.  For the most
part though it seems to be a combination of the two latter.  Only a
fairly small subset of PCI devices has been isolated to cause serious
problems, and it's fairly repeatable that removing these particularly
problematic PCI devices completely resolves all issues.  It seems to
me (and I'm guessing here again) that what we're seeing is a little
bit of an issue where VIA followed the spec to the T, and Intel
followed the spec to the T, but the two did so just the slightest bit
differently (anyone who's worked on this sort of thing can attest that
these specifications tend to leave a lot of room for speculation).
Then through in a company which exceeds the specifications, but does
so in such a way that they figure it shouldn't cause problems, and
then proceed to only test on a very limited subset of the available
hardware out there, and you run into a problems.

So, long story short, it does seem to me like VIA has a bit of fixing
up to do on their PCI bus arbitration, even if everything they're
doing follows the paper spec exactly.  It would seem that the de facto
industry spec (which is almost always slightly different then how most
would read the official paper spec) is just the tiniest bit different
then what they've got right now.  It would also seem that Creative
DEFINITELY needs to do some work on their drivers, because almost to a
one the reports all involved something that was somehow Creative
related, and in all cases replacing the card with a product totally
separate from anything coming out of Creative seems to fix the
problem(s).  For motherboards it's expected that a BIOS should fix the
problem easily enough, while for Creative Labs it seems like they
might actually have to release their first new driver for the SBLive!
in almost a year.

-----------------------
Tony Hill
hilla@uoguelph.ca



©2004 Google