Merkwürdiges Problem mit DFI LanParty NF4 SLI-DR - brauche dringend Hilfe!

12die4

Enthusiast
Thread Starter
Mitglied seit
08.11.2002
Beiträge
424
Hi alle miteinander, :wink:

Ich habe seit einiger Zeit ein DFI LanParty NF4 SLI-DR in meinem PC werkeln. Ich hab es auch wegen der großen Fangemeinde die auf das Board schwört gekauft und da es super zum Übertakten sein soll.
Mein altes Board (MSI K8N Neo2 Platinum) war da leider nicht so der Bringer, wobei ich nicht weiß ob es vielleicht auch an der CPU lag/liegt.

Nunja, jedenfalls bin ich bis gestern nicht dazu gekommen, mal ein bisschen mit den OC Einstellungen herum zu spielen um mich mit der Leistung des DFI vertraut zu machen.
Um das gleich mal vorweg zu nehmen: Da mein Erfolg mit dem MSI nicht grad groß war, zähle ich mich nicht zu den Profis was Athlon64 Overclocking angeht. Ich habe aber reichlich Erfahrung mit meinem alten AthlonXP-M (der seiner Zeit auf 2500MHz lief) und den CPUs davor gesammelt. Ich bin also kein Noob. ;)

Aaalso. Ich hab mich dran gesetzt und den FSB erstmal angehoben. Leider ging aber gar nix. Selbst bei nur 5MHz mehr FSB blieb der CPU beim Laden des WinXP Bootscreens einfach stehen. Tja, sehr ernüchternd.
Das wirklich kuriose ist aber: Während dem Übertakten sponn der Silicon Image RAID Controller, den das SLI-DR ja onboard hat, ziemlich rum. Mal piepte er und gab kryptische Anzeigen aus, mal erkannte er nur eine der beiden angeschlossenen Festplatten (die im RAID0 laufen), mal erkannte er sie aber auch fehlerfrei.

Tja, jetzt habe ich alles wieder enttäuscht auf Standard zurück gesetzt und wollte das Kapitel Übertakten nochmal nach hinten verschieben um eventuell mal eine andere CPU auszuprobieren. Jedoch:

Seit dem Übertakten ist mein zweites Array nicht mehr zu benutzen.
Ich muss wohl vorweg nehmen, dass ich zwei RAID Array in meinem System betreibe. Ein RAID0+1 aus vier Hitachi 7K250 Platten am NVIDIA RAID Controller, sowie ein RAID0 aus zwei weiteren Hitachi 7K250 Platten am Silicon Image und genau dieses RAID0 Array ist seit meinem kurzen OC-Versuch komplett verschwunden unter Windows.
Die Kabel habe ich natürlich alle überprüft, die sind in Ordnung - wie auch nicht anders zu erwarten. Beim Booten erkennt der SI Controller beide Platten fehlerfrei. Im RAID BIOS behauptet er sogar es bestünden keinerlei Konflikte, das Array sei einsatzbereit. Aber wenn ich in Windows bin werden die Platten weder im Arbeitsplatz, noch in der Systemverwaltung aufgelistet. Im Geräte-Manager ist das RAID Laufwerk ebenfalls verschwunden. Der Controller läuft aber auch laut Windows wunderbar.
Wenn ich die SI RAID Management Software starte, meldet er mir zwei angeschlossene Platten - eine davon als Orphan, also Waise, und eine als Spare, also als überschüssige Platte.

Irgendwie widerspricht sich der Computer also an mehreren Stellen selbst.

Mal unter der Annahme, dass die Angaben des SI Managers stimmen, wie kann es sein, dass ein RAID Array kaputt geht wenn man das System übertaktet? Das entzieht sich mir jeglichem Verständnis. Ich will daher der Software nicht glauben. Es muss einen Weg geben dieses augenscheinlichen Bug zu beheben.

Einfach ein neues Array darüber erstellen werde ich nicht. Ich hab schon oft genug damit herumgespielt und mir später in den Ar*** gebissen, Weil ich dann zur Datenrettung übergehen konnte.

Jedenfalls denke ich auch, dass bei Anschlusskonfiguration "Orphan/Spare" zumindest das Spare Laufwerk unter Windows angezeigt werden müsste. Schließlich war es auch so, als ich beide Platten ohne RAID Config das erste Mal anschließ: 2 Spare, beide im Geräte-Manager gelistet.


Ich bin mit meinem Latein am Ende. Hat jemand Vorschläge???
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
@12die4 hi,versuche mal die Platten an S-ATA 3+4 dranzuhängen und stell im Bios CPU Spread Spectrum aufjedenfall auf Disabled!!! Dann müsste es funtzen dann musst Du halt noch RAM feintuning machen :wink:
 
Em, also alle Spread Spectrums sind auf disabled und waren sie auch immer.

Du meinst also, ich soll die beiden Platten an die zwei noch freien Ports stöpseln?
 
Hab die Platten jetzt mal an die noch freien Ports gesteckt. Keine Veränderung. Das Array ist und bleibt unsichtbar. :(

Werd jetzt mal schnell ein BIOS Update versuchen.



GEHT IMMER NOCH NICHT! So langsam krieg ich die Krätze hier! :mad:
 
Zuletzt bearbeitet:
Es kann durchaus sein, das das Array durch OC beschädigt wurde.
So wie du es beschriebn hast, hatte der Controller ja schon Fehler beim erkennen der Platten. Bei so einem unstabilen Betrieb kann es sein das irgend ein Müll in die Partitionstabelle geschrieben wurde.

Mit viel Glück sind die Daten wieder da wenn du ein neues Array mit gleichen Parametern erstellst. Je nach dem ist evtl. noch ein fixboot/fixmbr über die Wiederherstellungskonsole erforderlich.
 
Ich frage mich wirklich, was das Erhöhen des CPU Takts mit einem PCI-Controller zu tun hat.
Die Boards haben doch alle seit Ewigkeiten einen PCI-Takt Fix. Das heißt, der Silicon Image müsste sich vollkommen unbeeindruckt von der Taktsteigerung zeigen!

Ausserdem: Ich habe ja nicht wild drauf los getaktet, sondern nur bis 220MHz Reftakt ausprobiert. Da kann man ja noch nicht von total instabilem Betrieb reden, das sollte eigentlich jeder Athlon64 mit machen - tja meiner nicht. Aber trotzdem kann die CPU nicht einfach unauthorisiert auf das Array zugreifen und dem Controller mal eben den Löschbefehl geben.

Wenn es so seien sollte, dann ist es mir echt unbegreiflich, wie man sowas konstruieren kann... :shake:
Und sowas nennt sich dann OC-Board? :stupid:


Also bevor ich da das Array neu erstelle muss ich es ja im Controller löschen. Vorher erlaubt der das Erstellen nicht. Und mit Array löschen und herumprobieren hab ich schon so meine Erfahrung. Bisher waren die Daten wie danach wieder da. Von daher lass ich die Finger davon, solange ich nix von DFI oder Silicon Image gehört habe.
 
Zuletzt bearbeitet:
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh