Epox 8k9a7i KT400 - Datenkorrption aif intakten HDDs

[kilg0r3]

Hi,

erstmal die Specs.

FILESERVER ALT (später FSalt genannt)

CPU: AMD Athlon 700Mhz (FSB100) lief auf (933 Mhz bei FSB 133, 1,85VCore)
MoBo: Epox 8kta2 8k9a7i (Rev 1.1)
ChSet: KT 133
SBridge: VT82C686B (die Berüchtigte)
RAM: Hynix + SDS PC133, lief auf 133Mhz
PSU: Coba 350W

DVD: Toshiba SDM1402
HD1: (IDE): Samsung SpinPoint SP 1604N (160GB)

VGA: ATI Rage 128 Pro (16MB)
NIC: Intel Pro 1000 GT (Jumbo frames disabled)
​

FILESERVER NEU (später FSalt genannt)
geänderte Komponenten habe ich mit * gekennzeinchet

CPU: AMD Athlon 700Mhz (FSB100) läuft jetzt innerhalb der Specs
*MoBo: Epox 8k9a7i (Rev 1.1)
ChSet: KT 400
*SBridge: VT8237
*RAM: TakeMS DDR 3200, 2x512MB, läuft auf 133Mhz stecken in Steckplatz 1 und 2
PSU: Coba 350W

DVD: Toshiba SDM1402
HD1: (IDE): Samsung SpinPoint SP 1604N (160GB)
*HD2: (SATAv1): Hitachi Deskstar HDS722516VLSA80 (160GB)

VGA: ATI Rage 128 Pro (16MB)
NIC: Intel Pro 1000 GT (Jumbo frames disabled)

Chipsatztreiber: Hyperion Pro 5.10

HD1 und HD2 sind technisch i.O. (geprüft mittles MD5Summer und h2test
​

WORKSTATION (später WS genannt)

CPU: P4 3GHz (Prescott)
MoBo: Abit Ai7
ChSet: Intel 865PE
Sbridge: ???
Ram: Corsair 2x512MB, laufen auf 200Mhz in DualCh.-Mode
PSU: Bequiet 450W

DVD: LG ???
CDRW: Mitsumi ???

VGA: Winfast Gforce 5600
Nic: Intel Pro 1000 GT (Jumbo frames disabled)
​

- Dateisystem auf beiden Rechnern ist NTFS ohne Kompression und ohne Verschlüsselung
- Auf beiden Rechnern läuft WinXP SP2 fully patched

Kurz gesagt stellt sich das Problem so dar, dass irgendetwas in dem System FSalt und FSneu Datenkorruption auf den Festplatten verursacht, obwohl die Platten in dem System nachweislich in Ordnung sind. Die habe ich nämlich in der WS mittels h2test getestet. Dort wurden je nach freiem Platz mit h2test 30GB bzw. 120GB Daten geschrieben und dann verifiziert. Außerdem wurden Dateien hin und herkopiert und danach mit MD5Summer geprüft. CPU und Speicher sind ebenfalls getestet (Prime95 und Memtest) und i.O.

Zuerst aufgefallen ist mir das Problem dadurch, dass Acronis es nicht schaffte auch nur ein intaktes Archiv von WS auf die HD1 des FSalt zu erstellen. Danach folgte eine Vielzahl von Tests in denen ich Daten von WS nach FSalt HD2 und die Quelldateien mittles MD5Summer verglichen habe.

Am Ende habe ich beschlossen, dass ich wohl ein Opfer des Southbridgebugs der VT82C686B wäre und habe mir das neue Epox gekauft. Aus FSalt wurde FSneu. Also, Neuinstallation und die ganzen Tests von vorne.

Der Schock trat dann ziemlich schnell ein. Die Daten gingen nicht nur auf dem Weg von WS nach FS kaputt sondern auch innerhalb des FS von HD1 nach HD2. Das ganze hat ewig zu testen gedauert, weil die Korruption so minimal ist. Dateien unter 2GB waren oft in Ordnung, manchmal aber eben auch nicht. Als ich das bemerkte, waren natürlich alle vorherigen Tests sinnlos und ich musste mit größeren Dateien nochmal beginnen. Am Ende stellte sich heraus, dass die Richtung der Kopieraktion völlig unerheblich war und das die Daten auch dann kaputt gingen wenn von sie innerhalb des selben Laufwerks kopiert wurden.

Hat irgendjemand eine Idee wo hier der Hase im Chilli sitzt? 120GB Grenze? Kaputte PSU? GIBT es AGP Karten die so ein Problem verursachen; habe leider keine andere zum testen?

Vielen Dank an alle, die sich bis hierher durchgebissen haben!!

 

[kilg0r3]

anybody?

 

[sapphire_pro]

Bist du ganz sicher das die Platten ok sind?

 

[kilg0r3]

Was die Platten angeht bin ich mir sehr sicher. Habe beide mittles h2test getestet. Das Programm schreibt daten auf die Platte die es dann hinterher verifiziert und meldete auf dem Testsystem keine Fehler. Außerdem habe ich auf dem Testsystem das Selbe gemacht wie auf dem kaputten. Kopien von großen Dateien erstellet und deren Prüfsummen verglichen. Auch die waren i.O. Außerdem hatte Acronis auf dem Testsystem keinerlei Schwierigkeiten mit seinen Archiven.

 

[kilg0r3]

anybody else

 

[sapphire_pro]

Kann es sein das auf dem PCI Bis zuviel Last entsteht?

 

[jni]

Sch... VIA-Zeug.
Wir hatten früher in der Firma ein Intel-Board mit VIA-Chipsatz als Server mit Win 2000 und IDE-Platten. Da gab's auch nur Probleme. Dann neu installiert mit Win 2003 Server und keinen extra Chipsatztreiber (W2003 Server bringt schon einen mit). Dann ging's ohne Fehler, allerdings der Transfer über die Netzkarte ging nicht besonders schnell.

Ich denke mal, XP SP2 hat auch einen VIA-Chipsatz-Treiber mit - wäre also mal zu testen ob's so geht.

 

[kilg0r3]

MANN!!

Um ganz sicher zu gehen habe ich am WE nochmal 48 Stunden Memtest laufen lassen. Irgendwann in dieser Zeitspanne haben die Module dann auch exakt _einen_ (!) Fehler gemacht. (War das jetzt die Ursache?). Daraufhin habe ich das gemacht, was man natürlich nie machen solle, wenn man einen Fehler wirklich finden will, nämlich mehrere Dinge gleichzeitig geändert.

1. Prozessor FSB und RAM gleichgetaktet die liefen vorher asynchron weil der Athlon standardmäßig nur 100 FSB macht. Jetzt läuft er wieder übertaktet auf 933Mhz und 133FSB (25% Übertaktung nicht schlecht oder? )

2. Den VCore auf 1,84 gestellt.

3. Ram Voltage um 0,1 erhöht

4. Ein Modul ausgebaut. Der Fahler tauchte bei 91 MB aus, weswegen ich in meiner naiven Logik das Modul aus der ersten Bank entfernt habe. Keine Ahnung, ob das jetzt richtig war oder nicht.

Danach wieder Tests. und was soll ich sagen es funktioniert. 30 Gig auf HD1 120 Gig auf HD2 mehrfach ohne Fehler geschrieben und gelesen. Acronis Backup von 30 Gig Größe geschrieben und validiert.

Tut mir leid wenn ich jetzt keine Lust habe noch mal jeden Parameter einzlen umzustellen und dann Tests zufahren. Ich denke die 0,1 V mehr Saft sollten die Rams aushalten. Und das Testen würde bestimmt weider 6 Stunden verbrauchen.

Was mich nur ärgert ist der erhöhte Stromverbrauch aufgrund der Übertaktung.

 

[kilg0r3]

Habe heute von Epox erfahren, dass die asynchrone Taktung von RAM und CPU FSB nicht unterstützt wird. Das scheint also wirklich der auslösende Faktor gewesen zu sein.