Mainboards, BIOS, Prozessoren, RAM 27.290 Themen, 124.050 Beiträge

Serien-Chipsatzfehler Elitegroup ECS K7VTA Rev 1.0

dl7awl / 13 Antworten / Flachansicht Nickles

[sorry, wenn das irgendwann 2x auftaucht, hatte zunächst versehentlich ohne Login gepostet]

Tja, Hilfe erwarte ich bei diesem Problem eigentlich nicht mehr wirklich, aber ich erzähle es trotzdem mal, weil es auch ein "Lehrstück" ist...

Lange Zeit war das Problem gar nicht richtig zu lokalisieren: das (damals) teuer bezahlte Mainboard nebst Athlon-CPU funktionierte unter Windows zunächst scheinbar leidlich, aber sporadisch gab es immer mal wieder Hänger und Abstürze. Die macht Windows (damals 98 SE) bekanntlich unter bestimmten Umständen auch gern von selbst, und auch Peripherie oder deren Treiber können schuld sein. Auch der befragte ECS-Support lenkte die Aufmerksamkeit in diese Richtung. Der problematische Rechner landete schließlich erstmal im Regal und verstaubte µit dem Vorsatz: Irgendwann wenn mal Zeit ist, gehe ich der Sache mal auf den Grund.

Das ist einige Zeit her, aber inzwischen habe ich mich nun doch mal drum gekümmert. Und jetzt steht fest: das Mainboard hat einen handfesten Hardware-Bug im VIA-Chipsatz, der unter anderem dazu führt, dass der IDE-DMA-Modus falsch arbeitet: bei jedem Festplatten-Lese- bzw. Schreibvogang besteht eine gewisse Wahrscheinlichkeit, dass Bytes unbemerkt verfälscht werden! Z.B. wenn man eine große Datei von einigen 100 MB kopiert, findet man bei anschließendem Vergleich mit dem Original (auf einem gesunden System) in bestimmten Abständen kleine Gruppen von falschen Bytes mit "Zufalls"-Inhalten. Das ist wohl das Fiesete, was einem Rechner passieren kann. Datenfehler können sich unbemerkt fortpflanzen, und es ist klar, dass sich mit so einem Board kein brauchbares System aufbauen lässt.

Übrgens kein Individualdefekt, sondern ein Serienfehler, wie inzwischen auch anderen Klagen im Netz zu entnehmen war, wenn auch nur vereinzelt, denn die sporadische Natur des Problems wird viele und insbesondere unbedarftere Nutzer in die Irre geleitet und gar nicht auf das eigentliche Problem geführt haben.

Darauf scheint sich auch ECS auszuruhen, obwohl sie nun - Jahre später - nach Konfrontation mit den Fakten unumwunden einen Chipsatzfehler zugegeben haben. Treiber mit Workarounds seien nicht verfügbar; eine andere Lösung als das Abschalten des DMA-Modus käme nicht in Frage. Na klasse! Die haben mein Geld und ich habe keine adäquate Gegenleistung! DMA-Modus kann man AFAIK unter Windows erst abschalten, wenn wenigstens die Installation sauber durchgelaufen ist, was ja bei so einem Fehler schon Glücksache ist. Oder kennt jemand wenigstens einen Weg, von vornherein "sicher" zu starten (so wie etwa bei Linux mit ide=nodma)? Apropos Linux: Auch das läuft trotz ide=nodma nicht anständig (sporadische Hänger), es scheint also noch weitere Chipsatz-Probleme auf dem Board zu geben (Verdacht: USB).

Natürlich ist die Garantie längst vorbei, ich hatte aber auf Kulanz gehofft, denn moralisch steht ECS tief in der Schuld. Schließlich muss man davon ausgehen, dass die defekten Boards damals WISSENTLICH verkauft wurden, denn so ein grobes Problem kann dem Hersteller eigentlich unmöglich verborgen bleiben - und bereits in der nächsten Board-Rev. war es ja auch behoben.

Aber ECS mauert. Die deutsche Support-Stelle (mittlerweile übrigens geschlossen) hatte nur dümmlichste Ratschläge parat und verwies mich wegen möglicher Kulanzleistungen an ECS Holland, wo ich mich auf Englisch melden müsse (was ich auch getan habe), aber dort wurde auf meine Mails gleich gar nicht reagiert.

Fazit: Geld für Schrott ausgegeben und auch noch viel Zeit damit verplempert. ECS hat wohl von tausenden betrogenen Kunden rechtlich gesehen nichts zu befürchten; kaum jemand dürfte ja innerhalb der Garantiezeit zu einem Beweis der Mangelhaftigkeit in der Lage gewesen sein. Man konnte also die Kunden erstmal mit falschen Ratschlägen in die Irre schicken und die Sache genüsslich aussitzen.

Mit einem BIOSTAR-Mainboard habe ich übrigens mal ganz andere Erfahrungen gemacht. Nachdem es sich geraume Zeit nach Garantie-Ende aus heiterem Himmel verabschiedete (kein Serienfehler, sondern individueller Defekt), gab es einen offenen und sehr freundlichen Kontakt mit BIOSTAR Deutschland, und das Board wurde ohne viel Aufhebens kostenlos ausgetauscht. Das Ersatzboard läuft heute noch. So geht es also auch!

Mein Fazit: Finger weg vom Billigmeier ECS, der sich selbst durch sein Verhalten als "skrupellos" zu erkennen gegeben hat. Und generell Vorsicht bei 1.0-Revisionen!

Ach ja, und noch eine Binsenweisheit: Etwaige Probleme sollte man frühzeitig untersuchen, um sie ggf. rechtzeitig reklamieren zu können. Nur: wenn das mal immer so einfach wäre; in diesem Fall war es das leider nicht...

Gruß, Manfred

bei Antwort benachrichtigen
dl7awl HeideUwe „Ich weiß nicht, wer hier der Schlaumeier ist? Ich habe nicht die Behauptung...“
Optionen

Na darauf lässt sich doch aufbauen. Auch wenn ich bei einigen Punkten schon wieder die Augen verdrehen muss:

a) Du hältst mir vor, keine Frage gestellt zu haben. Mag sein - vielleicht weil ich sowieso nicht mehr recht an eine richtige Lösung glaub(t)e. Aber auch wenn es nicht als Frage formuliert sein sollte - ist das Problem nicht trotzdem längst hinreichend klar geworden?

b) Ich hatte Gründe, ernsthaft an der Seriosität von ECS zu zweifeln (wozu ich auch ausdrücklich stehe und das bei Bedarf gern genauer belege). Aber wie kommst Du darauf, dass ich von meinem desolaten Board auf alle ECS-Boards geschlossen haben soll? Dazu geben meine Ausführungen nichts her! Also bitte sachlich und bei den Fakten bleiben!!!


So, das musste gesagt werden. Nun aber zurück zum Board und zu den von Dir mit Recht angeforderten weiteren Informationen.


BIOS und Treiber:

Meine Versuche haben natürlich zu jeder Zeit stets mit dem jeweils Neuesten stattgefunden, was man von der ECS-Website (www.ecs.com.tw) für das Board runterladen konnte. Bevor man das nicht probiert hat, sollte man generell keine Mängel reklamieren ;-)
Inzwischen ist das Board auf der ECS-Website nur noch im "Archiv" zu finden, mit folgenden "neuesten" Versionen, die demgemäß auch bei mir zur Anwendung kamen:

- BIOS: 1.2b vom 28.03.2003 (lt. Website; gemeldet wird aber 14.03.2002 bei gleicher Versionsnummer)
- 4-in-1-Chipsatztreiber: 4.56
- AC97 Soundtreiber: 3.50b

Hier der direkte Link (bitte lückenlos zu einer Zeile zusammenfügen):
www.ecs.com.tw/ECSWeb/Downloads/ProductsDetail_Download.aspx?categoryid=1&ty
peid=4&detailid=70&DetailName=Driver&DetailDesc=K7VTA3(1.0)&MenuID=45&LanID=0


System:

- Mainboard: ECS K7VTA3 Rev. 1.0
- CPU: Athlon XP 1700+ (Sockel 462).
- Speicher: 1 Riegel 256 mb PC2100 CL2 von Apacer


Nun zu der Frage, was ich im einzelnen versucht habe (soweit noch nicht vorher beschrieben):

Betriebssysteme: Die Versuche erfolgten mit diversen Linux-Versionen (Debian und mehrere SuSE) sowie mit Windows 98SE und XP(+SP2) - überall mit dem gleichen Ergebnis, d.h. Disk-I/O nur verlässlich wenn DMA abgeschaltet, was das System natürlich dramatisch und unakzeptabel ausbremst.

Alle Versuche wurden soweit möglich mit den Default-Einstellungen im BIOS vorgenommen (@hollebein: ja, stell Dir vor, SELBST ICH habe den Zugang ins BIOS gefunden ;-).
Konkret: zumindest bis ein OS incl. Chipsatztreiber usw. fertig installiert war, habe ich im BIOS sicherheitshalber die "fail safe" Settings verwendet, was auch die BIOS-seitige Deaktivierung von DMA beinhaltet. Erst danach habe ich testweise einzelne Einstellungen schrittweise in Richtung der "Optimum Settings" verändert. Und dann zeigt sich ganz klar: das geht immer gut, außer bei DMA. Sobald DMA freigegeben ist (natürlich auch im OS), gibt es regelmäßig Datenfehler beim IDE-Datentransfer.
Durch weitere Untersuchungen ließ sich das präzisieren: Die Probleme entstehen offenbar ausschließlich beim Schreiben im DMA-Modus. Lesen von der Platte scheint auch dann fehlerfrei zu sein, wenn DMA aktiv ist. (Das würde theoretisch Möglichkeiten für einen "selektiven Workaround" eröffnen, der die dramatischen Nachteile eines generell nur im PIO-Modus arbeitenden Plattenzugriffs vermeidet. AFAIK ist ein solcher Workaround aber für kein OS je realisiert worden).


Nun möchte ich noch was zu einigen hier bereits angeklungenen Vermutungen / Trugschlüssen zu bedenken geben:

a) Nachdem praktisch alle Probleme ganz klar und eindeutig einer ganz bestimmten Funktion (IDE-Schreiben per DMA) und einem von ECS ja auch zugegebenen Chipsatzfehler zugeordnet werden können und sich auch klar darauf beschränken, halte ich es bis zum Beweis des Gegenteils für unzulässig, meinem Board zusätzlich auch noch individuelle Macken zu unterstellen. Wer's darauf schiebt, macht es sich imho zu einfach. (Zugegeben, ich habe das vielleicht selber geschürt, indem ich weitergehende Probleme bei der Linux-Installallation erwähnte. Das hat sich jedoch inzwischen als SuSE-10.0-spezifisch und nicht repräsentativ erwiesen; mit allen sonstigen Versionen läuft's bis auf die einschlägigen DMA-Probleme einwandfrei; hab's gerade akut nochmal mit SuSE 9.1 getestet.)

b) Gleiches gilt für Vermutungen in Richtung Speichertiming: Um derartige Ursachen auszuschließen, gingen meinen Versuchen ausgiebige Speicherdauertests (komplette Testbatterie von memtest86) über mehr als 48 Stunden voraus, und zwar immer mit den kritischeren "Optimum Settings" im BIOS. Diese Tests verliefen ausnahmslos fehlerfrei; Speicherfehler oder falsches Speichertiming können also ausgeschlossen werden.

c) Schließlich würde ich auch mit der Behauptung / Vermutung vorsichtig sein, dass die DMA-Probleme sich auf große Files beschränken, nur weil sie da am sichersten nachweisbar sind. Selbst wenn das stimmen würde: was nützt das schon? Ich würde mich darauf aber sowieso nicht verlassen wollen. Keiner weiß schließlich, was sich z.B. im kranken DMA-Chip abspielt, wenn mehrere Dateizugriffe gleichzeitig stattfinden! Und selbst wenn bei kleinen Dateien 99% aller Transfers gut gehen sollten: für ein stabiles System reicht das bekanntlich nicht, es müssen 100% sein.


So, ich hoffe, das waren jetzt erstmal genügend Hinweise und Fakten. Jedenfalls ist das Problem präziser analysiert und klarer eingegrenzt worden, als man das von einem "DAU" normalerweise erwarten kann (sorry für den Seitenhieb, aber DEN miesen Schnellschuss habe ich wirklich übel genommen...).

Jetzt bist Du dran. Mit Deiner vollmundigen - bzw. um es netter zu sagen: MUTIGEN Lösungsgarantie (!!!) hast Du Dich ja weit aus dem Fenster gelehnt und gehst erheblich über das hinaus, was ECS höchstselbst bei diesem Board an "Lösungen" für möglich hält (nämlich nur plumpes DMA-Abschalten). Na denn man zu - wir sind alle ehrfurchtsvoll gespannt, wie Du das hinkriegst...

Es versteht sich von selbst, dass ich Dich dabei in jeder mir möglichen Weise unterstützen würde. Das Testsystem in der beschriebenen Konfiguration (z.Zt. mit XP+SP2 sowie SuSE 9.1) steht hier bereit, und Du kannst mich auch in jeder Weise "fernsteuern", um weitere Versuche oder was auch immer daran vorzunehmen. Keine Sorge, Du kannst mir alle in Frage kommenden Handlungen getrost zutrauen, bin nämlich vom Fach ;-) Ggf. kann ich auch den Remotezugriff aufmachen.

Master of Mainboards, der "bislang alle ECS-Mobos zum stabilen Betrieb bekommen" hat - bitte übernehmen Sie! ;-)

Gruß, Manfred

P.S.: Ehrensache, dass ein etwaiger Erfolg dann auch gebührend mit öffentlichen Lorbeeren hier im Forum gewürdigt wird - und meine ausgesetzte "Prämie" gilt natürlich sowieso weiterhin!

[Diese Nachricht wurde nachträglich bearbeitet.]

[Diese Nachricht wurde nachträglich bearbeitet.]

[Diese Nachricht wurde nachträglich bearbeitet.]

bei Antwort benachrichtigen
Ein Jahr später... dl7awl