8RDA+ und Silicon Image-RAID-Controller = massiver Datenverlust

Lord Voldemort

Vice Admiral Special
Mitglied seit
11.08.2003
Beiträge
764
Renomée
5
Hallo nochmal,

hier ein weiterer Teil meiner 8RDA+-Leidensstory. ;)
2 IDE-Ports sind mir zu wenig, und das stört mich auch ganz massiv am 8RDA+. :(
Also habe ich mir bei eBay einen RAID-Controller mit Silicon Image-Chip geholt (SiI 0680).
Wochen (!) später fiel mir rein zufällig auf, daß sehr große Dateien (>300 MB), die von der Festplatte am einen Port auf die Festplatte am anderen Port übertragen wurden, immer fehlerhaft waren! Bei 10 300MB-Dateien war nicht eine einzige richtig kopiert worden!! :[
Das hat mir einen Datenverlust im zweistelligen Gigabyte-Bereich beschert. *chatt*
Viel schlimmer ist, daß ich bis jetzt nicht weiß, welche Daten alle betroffen sind... *noahnung* Naja.

Natürlich habe ich alle Treiber- und BIOS-Versionen für den Controller ausprobiert, die ich finden konnte; nichts hat geholfen. Ich habe ihn sogar in einen reinen IDE-Controller verwandelt; auch das brachte nichts.

Dann fiel mir folgende Bemerkung in den Release Notes eines 8RDA3+-Bios auf:
Fixed the Sil3112A data loss issue when test RAID and write large files
Ach was! Das liest sich ja genau wie mein Problem! Mit der Ausnahme, daß eben das 8RDA3+ betroffen ist (najaaa, so anders ist das auch nicht! nForce2 eben!), und der Onboard-SATA-RAID-Controller, aber wieder Silicon Image! Zufall? Glaube ich nicht... ;)

Ich dachte mir, das könnte EPoX interessieren und schrieb dem Support folgende Mail:
Produktdaten:
------------------------------------------------------------------------
Seriennummer:
Typenbezeichnung: EPoX 8RDA+
Boardrevision: 1.1
BIOS-Version: ?
Verwendete CPU: Athlon XP 2400+ (Thoroughbred B )
------------------------------------------------------------------------
Verwendeter Speicher:
Bank1: 512 MB DDR 400 TwinMOS/Winbond
Bank2: 512 MB DDR 400 TwinMOS/Winbond
Bank3:
Bank4:
------------------------------------------------------------------------
Verwendetes Netzteil: Antec / 400W
------------------------------------------------------------------------
Verwendete Grafikkarte:
AGP: AGP / Sapphire Radeon 9700
PCI:
------------------------------------------------------------------------
Verwendete PCI-Karten:
Slot 1: Soundblaster Live! Player 1024 (CT 4760)
Slot 2: Hauppauge WinTV PCI
Slot 3: Realtek Ethernet
Slot 4: Silicon Image SIL 0680 UDMA 133 RAID
Slot 5:
Slot 6:
------------------------------------------------------------------------
Verwendete ISA-Karten:
ISA 1:
ISA 2:
ISA 3:
------------------------------------------------------------------------
IDE vorhanden?:
Primary Master: DVD
Primary Slave: CD-ROM
Secondary Master: CD-Brenner
Secondary Slave: Bitte wählen Sie...
Andere:
------------------------------------------------------------------------
RAID vorhanden?
Primary Master: Festplatte
Primary Slave: Bitte wählen Sie...
Secondary Master: Festplatte
Secondary Slave: Bitte wählen Sie...
Andere:
------------------------------------------------------------------------
SCSI Controller:
SCSI Geräte:
------------------------------------------------------------------------
Verwendetes Betriebssystem: Windows XP Prof. mit Service Pack 1
Fehlerbeschreibung:
Beim Kopieren vieler (>10) sehr großer (>300 MB) Dateien von der 1. auf
die 2. Festplatte am RAID-Controller (Silicon Image, SIL 0680, PCI) war
keine einzige Kopie identisch mit der Quelldatei. Kopiervorgänge, die
nur auf einer Festplatte abliefen, waren fehlerfrei. Die Festplatten
liefen in UDMA100, jeweils eine pro Anschluß, ohne ein Slave-Laufwerk,
am Ende (nicht in der Mitte) des Kabels angeschlossen und nicht im RAID.
Die Kabel sind bis UDMA133 geeignet. Dieselben Festplatten mit denselben
Kabeln laufen am Onboard-Controller des 8RDA+ fehlerfrei.

Der Fehler erinnert mich stark an einen Punkt in den Release Notes zum
BIOS vom 30.06.03 für das 8RDA3+:
"Fixed the Sil3112A data loss issue when test RAID and write large
files"

Mein Problem tritt ebenfalls mit einem Silicon Image-Controller und beim
Schreiben großer Dateien auf.

Welches BIOS für das 8RDA+ ich damals benutzt habe und welche PCI-Karte
in welchem Slot steckte, weiß ich nicht mehr. Inzwischen habe ich den
Silicon Image-Controller verkauft, weil ich nach mehreren zig GB (!)
Datenverlust keine große Lust mehr auf Experimente hatte.
Für mich sieht es jedenfalls ziemlich wahrscheinlich aus, daß der Fehler
beim 8RDA+ liegt. Da es sich um einen sehr ärgerlichen Fehler handelt,
sollten Sie dem Problem vielleicht mal nachgehen.

Können Sie mir einen RAID- oder IDE-Controller empfehlen, der mit dem
8RDA+ problemlos zusammenarbeitet?
------------------------------------------------------------------------
Was wurde bisher unternommen:
Ich habe diverse BIOS- und Treiber-Updates für den RAID-Controller
ausprobiert und den RAID-Controller probehalber per IDE-BIOS sogar in
einen nicht RAID-fähigen IDE-Controller verwandelt. Außerdem habe ich
ein zweites Windows XP installiert, bei dem dieselben Fehler auftraten.

Alle diese Maßnahmen konnten das Problem nicht lösen.

Die Antwort hat mich sehr enttäuscht:
Sehr geehrter Kunde,

Wenn Sie Probleme mit einem Raidcontroller haben,
können Sie im bios die latency times etwas erhöhen.
Empfohlen sind Werte um 64-128.

Innstallieren Sie bitte auch die neusten Treiber
für Ihre Soundkarte

Eine andere PCI-Slot Kombination können Sie auch testen.

Das ist also der vielgelobte EPoX-Support? :[
Ich habe darauf nicht mehr geantwortet, weil ich keine Zeit und außerdem den Controller inzwischen schon weiterverkauft hatte (mit Hinweis auf eventuelle Probleme natürlich... :] ).


- Tja, meine Frage wäre also, ob noch jemand zufällig Erfahrungen mit einem 8RDA+ und einem SiI 0680-basierten RAID-Controller (oder überhaupt einem Silicon Image-RAID-Controller!) gemacht hat.

Achso, nochwas: natürlich (!) habe ich probehalber die doch erhebliche Übertaktung meines Systems zurückgenommen. :]
Und am IDE-Controller des Boards tritt das Problem nicht auf.


Gruß,
Lord Voldemort

P.S.: Ich hab inzwischen einen Promise Fasttrak 100 TX2 hier liegen, hab nur leider keine Zeit, ihn einzubauen. :( Bin mal gespannt, ob der fehlerfrei läuft! ;)
 
wie schön, dass ich diesen thread noch mal wieder gefunden habe.

ein freund von mir hat nämlich kürzlich EXAKT das gleiche problem gehabt.

hat auf seinem abit nf7-s 2.0 eine neue platte nachrüsten wollen (samsung p80) und zu
dem zweck einen dawicontrol dc133 mit sil0680 nachgerüstet.

vorher lief das system einwandfrei, nach einbau des controllers waren seltsamerweise
ALLE dateien, die von der samsung aus oder auf die samsung kopiert wurden am zielort
corrupt.

wir haben da ein paar tage rumprobiert, auch unter zuhilfenahme des p3d nforce2 config
guides, alles ohne erfolg.

beim sil0680 sind auch nicht nur, wie im config guide im falle des sil3112a beschrieben,
grosse dateien betroffen, sondern tatsächlich alle.


irgendwann hatten wir keinen bedarf mehr, weiter an dem problem rumzubasteln. den dawi
hat mein freund bei ebay vertickt und gegen einen promise ultra133 tx2 ausgetauscht. bisher
läuft das system jetzt wieder ohne probleme.


mfg
cruger
 
Zuletzt bearbeitet:
Ich kann nur vom Abit sprechen und da war die Datenkorruption an der Tagessordnung
mit dem SIL0680 Chip ...erst ab dem 14er Bios (rev2.0 ) war es wie es scheint in Ordnung ...dann gab es da noch ne Einstellung im Bios die ich auf 1ms gestellt habe (Zugriffszeit?!)
 
bios haben wir 1.7 und 1.8 ausprobiert, beim sil0680 1.0.1.7 und 1.0.1.8. hat nix gebracht.

welche einstellung im bios meinst du ? ide initial delay ?


mfg
cruger
 
Wie gesagt ich habe das Abit NF7-S
So 14er Bios
Treiber 10028
Und die Einstellung ist bei ...Integrated Peripherals...dann EXT-P2P s Discard Time
da hatte oder habe ich 1ms
 
Original geschrieben von freezer1
Ich kann nur vom Abit sprechen und da war die Datenkorruption an der Tagessordnung
mit dem SIL0680 Chip ...erst ab dem 14er Bios (rev2.0 ) war es wie es scheint in Ordnung ...dann gab es da noch ne Einstellung im Bios die ich auf 1ms gestellt habe (Zugriffszeit?!)

das ist aber der treiber für den onboard sil3112a des nf7-s.

wir sprechen hier über den sil0680a.


mfg
cruger
 
jo auch gesehen ...den 680 (also den PCI Raidcontroller ) hatte ich vorher ...da kann ich nur soviel sagen das ich da noch die Datenkorruption hatte aber ihn verkauft habe BEVOR !! das neueste Bios rauskam das die Sache ja in Ordnung bringen sollte
 
ok mein problem wurde jetzt sehr wahrscheinlich durch durch den patch Q331958 gelöst. bis jetzt keine einzige korruption mehr!!
installieren schadet sehr wahrscheinlich nicht und kann nur nützlich sein :D
 
SI verkaufen, HPT kaufen und das Problem ist gelöst (ohne Mehrkosten). Oder von vorn herein informieren ob mit der angestrebten Kombi Probs gibt .....
 
öhm ich hatte das korruptionsproblem mit hpt!! von daher muss das auch nicht unbedingt _die_ lösug sein *noahnung*
 
ich hab mal auf der silicon page ein bios für den onboard-controller gesehen, dass man selbst flashen könnte, vielleicht gibts ja sowas auch für deinen
 
naja sowohl das bios vom mainboard als auch das bios vom highpoint sind die neusten. alles andere ist auch am neuesten. naja gerade eben hat mir windows wieder angst gemacht und chkdsk beim starten gemacht :((
aber war nur das mit $30 - indexeinträgen aufräumen
hoffentlich ist es auch wirklich weg bei mir
naja mal sehen
 
habe ebenfalls ein raid controller mit oben genannten chip, auf dem 8rda+ rev 1.0 mit aktuellstem bios keine probleme
 
Hab seit Freitag das NF7-S Rev. 2.0 von Abit + Sil680 mit 2 Maxtor 40GB Platten als Raid 0...

Hatte DesertCombat0.4j runtergeladen ist etwas mehr als 500MB. Beim entpacken bekamm ich mehrere CRC Error. Nachdem ich wie hier schon beschrieben die EXT-P2P s Discard Time von 30us auf 1ms erhöht hab kann ich kopieren so viel ich will ohne Fehler. Hab zum Test dann wieder 30us und sofort gab es wieder CRC Fehler...

Das 8RDA+ müsste doch eine ähnliche Option haben?
 
Wo ich es noch hatte gab es keine !! Lösung ..mit dem Sil Chip ,mit dem HP Chip sollte man darauf achten einen 370 oder 370 A zu haben ...aber jetzt mit dem 14er Bios (Abit) soll es wohl gehen kein Chdisk keine verlorenen System32 Ordner usw

@Saiotek
genau (nehme an hast das 14er bios) und die Option wo man die 30ms oder die 1ms einstellen kann ...da sollte man 1 ms einstellen
 
Das Problem mit der Daten-Korruption ist ein hinlänglich bekanntes. Trauriger Weise ist es aber nicht das Verschulden der SiliconImage Controller (oder vom Hersteller xyz), sondern vielmehr das des nForce 2 Chipsatzes! Beim Abit NF7-S fingen alle früh an zu schreien, weil die Daten auf den Festplatten, die am SiliconImage S-ATA Raid Controller hingen, nach einiger Zeit schlichtweg unbrauchbar wurden. Nach langem warten ist dann Nvidia irgendwann aufgewacht und hat mit Hilfe von SiliconImage das Problem mit besagtem BIOS FIX (glaube ab version 14 beim NF7-S Rev2) beseitigt. Das Epox 8RDA+ hat natürlich wie alle anderen nForce 2 Boards die selben schwachstellen im PCI-Bus und verhält sich daher bei einsatz eines PCI-Controllers genauso wie das Abit ohne BIOS FIX. Nur hat hier eben kaum einer aufgeschrien, da das Epox ja keinen OnBoard Controller hat, der via PCI angebunden ist.

btw: Der P-ATA Controller des nForce 2 ist nicht davon betroffen, da er nicht per PCI angebunden ist!

--
mfG
Skyfighter
 
ich hatte das gleiche prob vor einiger zeit (epox 8rda, sil0680, winxp) ich habe nach vielen wochen neu formatieren einfach mal win2000 probiert, seit dem geht es!
 
Keiner sprach hier je ueber Promise. Denen kann ich bescheinigen, dass sie problemlos laufen (bisher 2 gehabt, einen onboard, einen PCI). Gut auch, dass man die Platten problemlos an jeden Promise RAID-Controller haengen kann - jeder Promise kann jedes Array erkennen, bei Highpoint geht das AFAIK nicht, wenn der Chip ein anderer ist.

Habt Ihr aehnlich gute Erfahrungen mit Promise? Stoeren tut mich eigentlich die elend lange Bootzeit.
 
bekommt man das bios fix auch fürs 8rda+ und wenn ja wo???
 
würde mich auch interessieren. auch wenn ich bis jetzt keine korrupten daten habe. aber ich kopiere auch nicht viel zwischen den paritionen bzw. platten an verschiedenen kontrolern rum. was mal aufm raid is bleibt in der regel auch dort.

lol da hab ich mich wohl mal dick im datum verguggt :)
 
Zurück
Oben Unten