nForce 4 gleiche Probleme wie KT133A??? Binärfehler!!!

mulle78

Enthusiast
Thread Starter
Mitglied seit
03.12.2003
Beiträge
43
Hallo @all,

ich habe ein Problem mit meinem DFI LanParty Ultra, mit dem nForce 4 Chipsatz, für den Sockel 939. Manchmal sind beim Datensichern mit Nero nach dem Check Bitfehler auf den Medien aufgefallen, was ich aber noch auf die Medien selbst geschoben hatte. Der Fehler kam selten vor und betraf zum Glück bisher nur private Fotos die sich nach dem Brennen trotzdem weiterhin öffnen ließen. Bei Medien mit anderen Inhalten habe ich diese weggeworfen, neu gebrannt und dann trat der Fehler nicht mehr auf. Er erschien also nicht repoduzierbar.

Nun bin ich dazu übergegangen, die Daten vorher schon per Software in ein ISO-File zu packen und dieses später zu brennen. Die ISO-Files habe ich vorher entpackt, um die Daten mit der Software Filesync 2.18 binär zu vergleichen. Und tatsächlich, bei großen Dateien traten vereinzelt Bitfehler auf. Die Daten gingen bei dem Test immer von einer HDD auf eine andere. Zu anderen Tests bin ich noch nicht gekommen. Dieses Problem und da ich auch vom KT133A Bug stark betroffen war, haben mich veranlasst ein altes Script hervor zu kramen.

Über Nacht habe ich mit dem Bordeigenen Tool "fc" einen ca. 4 GB großen Datenbestand in Dateien von 50 bis 400 MB aufgeteilt immer wieder von einer HDD auf eine andere kopieren und vergleichen lassen. Von 1385 kopierten Dateien sind vier unterschiedlich:

0049A5AA: 09 01
008DE5AA: 0A 02
023615AA: 28 20
05A3B5AA: 2F 27

An meinem Rechner habe ich am primären Controller ein WD 160 GB und einen LG Brenner und am zweiten Controller eine WD mit 250 GB und ebenfalls einen LG Brenner.

Hier das Script:

Code:
REM :fc oder comp
SET methode=fc

REM :Bitte sourcen angeben im Stiel c:\abc\xyz
SET source=E:\QUELLE
SET target=D:\PRUEFEN

FOR /F "TOKENS=1* DELIMS=\ " %%z IN ("%source%") DO SET lw=%%z
FOR /F "TOKENS=2,3,4* DELIMS=. " %%i IN ("%DATE%") DO SET INF_DATE=%%kj_%%jm_%%id
FOR /F "TOKENS=1,2,3,4* DELIMS=:, " %%i IN ("%TIME%") DO SET INF_TIME=%%ih.%%jm.%%ks.%%lms

%lw%
cd "%source%"
del *.mylog

:schleife

xcopy /R /Y "%source%\*.*" "%target%"
IF %methode%==comp FOR %%f IN (*.*) DO %methode% "%source%\%%f" "%target%\%%f" /D >>"%temp%\logfile_from_%INF_DATE%_%INF_TIME%.mylog"
IF %methode%==fc FOR %%f IN (*.*) DO %methode% "%source%\%%f" "%target%\%%f" /B >>"%temp%\logfile_from_%INF_DATE%_%INF_TIME%.mylog"
del /Q /F "%target%\*.*"

goto schleife

REM c:
REM cd\

notepad "%temp%\logfile_from_%INF_DATE%_%INF_TIME%.mylog"

Im Einsatz habe ich die Standard Microsoft IDE Treiber, da ich mit den nForce Treibern akute Geschwindigkeitseinbrüche auf dem BUS festgestellt habe, wenn mehrere Tasks parallel Daten von HDD 1 zu 2 und umgekehrt schicken. Ebenfalls lassen sich nicht parallel Daten Brennen und das ist für mich existenziell. Alle Dokumente halte ich doppelt vor und brenne sie zur gleichen Zeit um Zeit zu sparen.

Im Betrieb sind mir keine Stabilitätsprobleme aufgefallen. Prime95 rechnete nach meinem Übertakten Nächtelang ohne Fehler.

Hier die Einstellungen: Venice 3200+ auf 2350 MHz, Referenztakt auf 235 MHz, HTT auf 4X mit 960 MHz, RAM mit DDR333, also mit 195 MHz, die CPU läuft mit 113% vCore, also mit 1,5 statt 1,35 Volt. Alle Komponenten außer der CPU sind also in der Spezifikation betrieben.

Ich werde mein System einmal auf Standard takten und schauen ob ich immer noch Bitfehler habe, es könnte ja an der übertakteten CPU liegen?! Oder…

Kann sich einer die Mühe machen und seinen Chipsatz in einer ähnlichen Konfiguration mal auf Herz und Nieren prüfen?!
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
da haben wir es, auch bei Standardtakt Bitfehler:

02FB55AA: 0A 02
 
Deaktiviere ich auch bitte jegliche "automatische" Übertaktung im BIOS etc. Falls möglich, kannst Du Deinen Prozessor gegen einen anderen tauschen? Nur zum Testen. "Normalerweise" treten diese Fehler nicht auf. Kannst Du überprüfen, ob eine Einheit defekt ist? Wie? RAM wieder auf 333?
 
Zuletzt bearbeitet:
Wie geschrieben tritt der Fehler auch bei Standardtakt auf. RAM ist mit memtest86 getestet, wie aussagekräftig das auch immer ist. Die Komponenten liefen alle vorher auf einem ASUS mit SiS Chipsatz einwandfrei. Alles übernommen, Kabel und Platten.

Das jetzige System läuft ja auch super... wenn ich nicht ständig bei Nero mit Verify arbeiten würde und vieles noch mal binär vergleichen würde (weil KT133A geschädigt) wäre mir das Problem zu lebzeiten wohl nicht aufgefallen.

Zur Ziet kopier ich die Daten über einen Kanal auf die selbe Platte, mal sehen was da zu sehen ist. Vielleicht besteht das Problem auch nur wenn ich von Kanal a auf b kopiere.

Im BIOS wird zur Zeit garnix mehr übertaktet... siehe
da haben wir es, auch bei Standardtakt Bitfehler:
02FB55AA: 0A 02

CPU habe ich leider keine zum tauschen, prime95 sagt aber, das alles OK ist.

RAM kann ich mal deutlich unter der Spezifikation betreiben... evtl. ist er doch zu schwach.
 
Zuletzt bearbeitet:
Gehen wir's mal akademisch an: Wir sagen, dass es keinen Bug gibt. Wo liegt dann der Fehler?

Möglich sind Defekte in der CPU, im RAM und im Chipsatz.

Leider ist Memtest in diesem Grenzbereich nicht zuverlässig genug. Selbst tagelanges Testen könnte den Fehler u.U. nicht aufdecken. Kannst Du noch sagen, was für einen Brenner Du verwendest inkl. Firmware, Revisionsdatum etc.? Du könntest versuchen, alles unterhalb der eigentlichen Spezifikation zu betreiben, also geringerer HTT, nur 333/266Mhz, kein 1T, sondern 2T etc. Ist wirklich irgendwo ein Fabrikationsfehler drin, werden den wohl kaum feststellen können. Hilft Google gar nicht weiter? Wir werden doch ein paar Standardsachen abklappern, aber das ist wohl eher etwas Stochern im Nebel: Sind Deine Kabel IDE wie SATA kurz genug, d.h. bei IDE unter 45/48cm? Bist Du sicher, dass Du beim Einbau/Umbau niemals mit dem Schraubenzieher *versehentlich* übers Mainboard o.a. geschrammt bist? Hab ich auch schon gesehen.
 
Zuletzt bearbeitet:
KühlschrankPC schrieb:
Kannst Du noch sagen, was für einen Brenner Du verwendest
An dem liegt's nicht; er hat die Fehler ja auch in Images.

Was mir noch einfiele, wären Tests mit 'nem anderen Brennprogramm, falls verfügbar; XP kann ja beispielsweise auch (notdürftig) selbst aus dem Explorer brennen.
 
Ich tausche mal die Kabel und stelle alles unterhalb der Spezifikation ein. Sind EIDE Geräte. Meine SATA Platte kommt wohl erst nächste Woche. Wenns nur die Kable wären, das wäre ja super... an sonsten seh ich wohl alt aus.

Brenner sind zwie LG GSA-4163B mit A105 Firmware. Alles aktuell. Auch das DFI Board hat das letzte aktuelle Final BIOS.

Kabel sind zwar Rundkabel, aber in der Länge nach Spezifikation. Sind sogar getwisted... also nicht die aufgeschnipselten Flachbandkabel. Werde diese aber mal tauschen, auch wenn das System vorher auf einem A7S333 mit diesen Kabeln und Platten einwandfrei lief. Dort hatte ich, da es das Nachfolgesystem des KT133A war, nach Einbau auch dien Binärtest ein Weile laufen lassen. Dort sind mir nie Defekte aufgefallen.

Ich hoffe mal ich habe kein defektes Board.

Ich melde mich, sobald ich noch ein wenig getestet habe....
 
ganz spontan tippe ich mal auf den RAM ;)
hast du vllt mal nen anderen zum testen?


CB
 
Hallo

Hatte auch mal Probleme mit CRC Fehelr oä.
Daten wurden auf DVD od. CD gebrannt. Anfangs dachte ich mir auch, wer solche Rohlinge kauft ist selber schuld. An den Rohlingen hats nicht gelegen, genausowenig am Brenner. Letztendlich war es die Festplatte, die ich danach mit allen erdenklichen Programmen auf Fehler getestet habe - allerdings kamen die Progs zum selben Ergebnis, dass die HDD in Ordnung sei.
Besorgte mir dann ne neue Platte und siehe da, die Fehler traten nicht mehr auf.
 
also der RAM ist "NONAME".... eigentlich Corsair zwei mal 512 MB CL2,5 DDR400

habe jetzt mal auf DDR333 getaktet und siehe da, deutlich weniger Fehler, aber nicht Fehlerfrei:

HD1 160GB 450 Kopien ohne Fehler
HD2 250 GB 911 Kopien und troz runtergetaktetem Speicher ein Fehler
00EF65AA: 2E 26

Da die Feherrate statistisch so drastisch gesunken ist, ist ja schon mal ein Lichtblick. Was meint ihr... ist das nun ein Chipsatzproblem oder ein Speicherproblem... ob ich mal auf Single Chanel umstelle?

Aber allgemein muss ja der Chipsatz ein Problem haben, gibt ja doch par Threads über das Thema im i-Net. Gerade weil er auf der langsameren Systemplatte nicht so häufig aufgefallen ist und die Installation bei mir quasi steht und höchstens beim Defragmentieren Daten verschoben oder kopiert werden, ist mir das alles erst jetzt aufgefallen.
 
Ich würde empfehlen, noch weiter herunterzutakten, auf DDR266 und ggf. auch DDR200. Funktioniert es dann fehlerfrei, kann immer noch der Speichercontroller in der CPU oder der RAM defekt sein, aber deutet sehr stark auf RAM. Wie gesagt, eine Wahrscheinlichkeit. Ein weiterer Vorschlag: DDR333 UND Single Channel, treten hier keine Fehler auf, allerdings dann bei DDR333 UND Dual Channel bist Du wieder einen Schritt weiter. Wie gesagt, teste mal auch mit nur einem RAM-Riegel.

Es ist eben sehr schwierig, hier eine Diagnose zu stellen, da die Datenkopiererei die CPU, den RAM, den Chipsatz und die Festplatte betreffen.
 
Zuletzt bearbeitet:
Übertakter aufgepasst:

Übertakter aufgepasst:

Den Fehler konnte ich bei Corsair unterbinden, indem ich alle Spezifikationen eingehalten habe.... der MDT ist eingebaut und der Test bei Standardtakt ist zufriedenstellend verlaufen, keine Fehler bei 4000 (2x2000) kopierten Dateien (SATA HDD auf sich selbst und von IDE auf eine andere IDE, bei der ich vorher die Fehler hatte)

jetzt gehts wieder ans Übertakten und das alles mit MDT, statt Corsair. Ich habe eben mal den Speicher wieder auf DDR333 (166MHz) gestellt und den Referenztakt auf 235 MHz um die alten Einstellungen zu fahren. Dabei habe ich den Bluescreen PFN_LIST_CORRUPT erhalten, der ebenfalls auf Speicherprobleme hindeutet. Da der MDT Speicher ein sauberes SPD hat und dort auch Werde für DDR333 stehen, habe ich nicht nur die über CPUZ angezeigten Werte Tcl, Trc, Trcd und Tras fix gestellt, sonder mir ist aufgefallen, dass laut A64Tweaker auch die Werte Trfc und Read Preamble nicht wie vor bei DDR400 (200MHz) liefen.

Nun habe ich einfach mal alle Einstellungen so wieder eingestellt für das übertaktete System, dass ich alle Werte (Spannung, Speicher, HTT Multi) angepasst habe, ausser den Referenztakt. Nun läuften Trfc mit 14 Takten fix, wie bei DDR400, statt 12 wie bei DDR333 AUTO und Read Preamble mit 5,5ns fix wie bei DDR400 statt 6,5ns bei DDR333 automatisch eingestellt (wobei ich mich hier wundere, dass der Wert bei langsamer getaktetem Speicher höher ausfällt, also eine höhere Latenz angegeben ist).

Ich bin mir nicht sicher, ob ich das damals beim Übertakten des Corsair berücksichtigt hatte, denn auch diesen musste ich mit DDR333 fahren, damit er beim Übertakten nicht über 200 MHz lief. Jetzt kann ich die Trfc und Read Preamble Werte nicht mehr vergleichen, da schon ausgebaut.

lasse ich jetzt Clockgen über Windows laufen, verrechnet sich die CPU laut Prime erste bei ca. 2,5 GHz statt 2,0 GHz Default.

[EDIT]
Bei mir im BIOS wird der Read Preamble Wert anderes ausgelesen/angegeben, wie von A64Tweaker interpretiert. Musste den Wert im BIOS auf 5,0 ns stellen, damit er wie bei der automatischen Einstellung vom BIOS bei DDR400, in A64Tweaker mit 5,5 ns angezeigt wird. Mit dem korrekten Read Preamble Wert und dem korrekten Trfc Wert fuhr er jetzt auch mit einem Referenztakt von 235 MHz hoch und das bei DDR333 Einstellung.

Ein Schnelltest mit Windows Software ließ bei DDR333 die CPU bis 2,52 GHz und RAM bis 209 MHz zu und bei DDR366 (183MHz) bis 2,48GHz und RAM bis 226 MHz. Ich denke da sollten 2,35 GHz und DDR333 im Ramen sein, also CPU 2,35 GHz und RAM 195 MHz. Oder was meint ihr?[/EDIT]

[EDIT2]
So Jungens und Mädels, ich kann jetzt wieder beruhigt schlafen.

Der Rechner lief jetzt sauber 24 Stunden durch. Prime95 hat keine Fehler gemacht und die Platten auch nicht. Von IDE1 auf IDE 2 4501 Kopieen ohne Fehler und auf der SATA Platte 3731 Kopieen ohne Fehler. Und das bei Athlon64 3200+@2350 MHz; RAM 195MHz@DDR333 mit gefixten Timings und Spannung auf der CPU bei 113% (1,54 Volt). Eventuell versuch ich die CPU noch etwas zu entlasten, indem ich die Spannung etwas senke.

Wenn es nicht am Speicher lag, dann lag es wohl am Trfc und Read Preamble Wert, die durch AUTO Einstellung über das BIOS zu scharf eingestellt waren, denn der Speicher lief auf DDR333, aber mit Taktraten von DDR400.

Obwohl, ich meine mich zu erinnern, dass ich beim Corsair einen Fehler bei Defaulttakt hatte.... von etlichen Versuchen, aber einen Fehler. Der MDT läuft bei mir jetzt jedenfalls einwandfrei.
[/EDIT2]
 
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