BIOS-Updates gegen Datenbeschädigung durch VIA-Chipsatz

Die Mainboard-Hersteller reagieren auf den Fehler in der VIA-Southbridge 82C686B, durch den der Chipsatz teilweise Daten während Festplatten-Transfers beschädigt. Sie veröffentlichen einige BIOS-Updates zur Beseitigung der Fehler; doch Tests im c't-Labor zeigen: Diese Updates helfen nicht immer.

Die Aktualisierungen der BIOS-Software befinden sich im Beta-Stadium; einige Hersteller stellen sie nicht öffentlich zur Verfügung, sondern sie liegen bei verschiedenen Hardware-Sites:

• Abit: Die Version ZT (Beta) KT7 von der Beta-Seite soll den Fehler beheben.
• Asus: Bei Planet 3DNow! sind Updates für das A7V (1008 1B) und A7V133 (1004 2D) zu finden.
• Enmic (NMC): Die offizielle Version 8TTX+ ist derzeit auf der Update-Seite noch nicht verlinkt.
• Epox: Auf einer speziellen 686B-Update-Seite stehen BIOS-Aktualisierungen für das 8KTA2 und 8KTA3/3+ bereit.
• Iwill: KK266, KK266-R (offiziell); bei AMDZone liegen die Updates für das KA266 und KA266-R; ein neues Flash-Programm scheint notwendig.
• MSI: Bei AMDZone gibt es ein Update für das K7T Turbo, das den Fehler beheben soll.
• Soltek: Die Version K3 für das 75DRV (offiziell) soll den Fehler beheben, doch Soltek selbst erwähnt davon nichts.
• VIA: Auf der offiziellen Seite tut sich was: Dort finden sich auch die Dateien von Epox und Iwill, weitere BIOS-Updates haben demnach AOpen, Biostar, ECS/Elitegroup, Gigabyte und Legend QDI angekündigt.

Nach Tests im c't-Labor beheben diese BIOS-Updates den Fehler jedoch nicht zuverlässig. Auch Boards mit neuem BIOS und mit allen bekannten Work-Arounds produzieren Fehler: Sobald Daten über den zweiten IDE-Kanal fließen, während der PCI-Bus unter hoher Last steht, können diese Daten verfälscht werden. Betroffen sind nicht nur Boards mit der VIA-Northbridge KT133A: Übertragungsfehler traten auch auf Boards mit der AMD-Northbridge AMD-761 auf.

Der Fehler scheint auf den zweiten IDE-Kanal beschränkt zu sein: Sobald nur Transfers zwischen Geräten am ersten Kanal oder an separaten IDE-Controllern stattfinden, arbeiten alle Systeme stabil. Doch sobald Geräte am zweiten IDE-Kanal hängen, treten die Fehler auf — auch beim Kopieren von einem RAID-Controller zum zweiten IDE-Kanal der 686B. Falls Datentransfers zwischen Master und Slave am zweiten IDE-Kanal stattfinden, traten die Abstürze sogar gehäuft auf.

Der Nachweis des Fehlers gelingt oft nur mit viel Geduld: Bei einigen Boards trat erst nach mehreren Stunden die erste Störung im Datentransfer auf. Eines der Boards, für das schon ein BIOS-Update existiert, lief im c't-Labor ohne Aktualisierung des BIOS und mit kritischen Einstellungen ohne Fehler. Nicht auszuschließen ist auch, dass mehrere Fehler oder Instabilitäten in die Tests mit einfließen. So soll ein Mitarbeiter eines Mainboard-Herstellers betont haben, dass sich mit jedem Bugfix neue potenzielle Fehlerquellen ins BIOS-Setup einschleichen können.

Nicht endgültig entschieden ist auch, ob die Soundblaster-Karte, die bei fast allen Nachweisen des Fehlers zum Einsatz kommt, für die Störungen verantwortlich ist. Auch im c't-Labor laufen alle Systeme ohne diese Karte stabil. Die Ursache für Störungen können Konflikte zwischen der Karte und dem Onboard-Sound sein. Zu empfehlen ist also, beim Einsatz einer Soundkarte den Onboard-Sound zu abzuschalten – falls möglich (per Jumper und BIOS-Setup). Falls nicht, sollten unter Windows zumindest die Onboard-Sound-Treiber (meist "AC97 WDM" oder ähnlich) deaktiviert werden. Bei der Konfiguration der Soundblaster-Karten könnte auch die SB16-Emulation Schwierigkeiten verursachen: Man muss einige ISA-Ressourcen für diese PCI-Karte reservieren (siehe Hotline-Tipp vom November 1999). Die Soundblaster-Karten erzeugen laut einiger Support-Mitarbeiter eine unnötig hohe Last auf dem PCI-Bus; das spricht zwar gegen die Karte oder deren Treiber, aber der PCI-Bus sollte mit dieser Last klar kommen. Leser berichteten c't, dass sie auch mit anderen PCI-Geräten, die eine hohe Buslast erzeugen, die Datenverluste an der 686B-Southbridge beobachten. Die Soundblaster-Karte sorgt also wohl nur für verstärktes Auftreten des Fehlers, aber nicht für den Fehler selbst.

Im c't-Labor erwies sich als einziger funktionierender Workaround, den zweiten IDE-Kanal nicht zu benutzen. Dann liefen bisher alle Systeme stabil, auch unter etwas härteren Bedinungen (etwa gleichzeitiges Kopieren vom IDE-RAID auf 686B-Kanal, Kopieren vom IDE-RAID auf 100-MBit-Netzwerk, sich ständig bewegende USB-Maus, Abspielen von MP3, Swap-Datei auf 686B-Kanal). (jow)