| Beitragsrückblick für nForce 4 gleiche Probleme wie KT133A??? Binärfehler!!! (die neuesten Beiträge zuerst) |
|
Gibtnix |
Erstellt: 11:26 am 4. Dez. 2005 |
mal ein anderer Ansatz woher das Problem kommen könnte; so wie ich dich verstehe benutzt du SATA-HDDs und gleichzeitig einen Referenztakt von 235 MHz? Die SATA-Ports 1+2 sollen beim Übertakten teilweise Probs machen, da der Controller nciht ganz korekt gefixt wird. Behoben kann dieses Problem durch verwenden von Port 3+4.
Dagegen dass es an einem zu scharfenRam-Timing lag spricht dass weder Memtest noch Prime angeschlagen haben - dadurch wird das System so stark ausgelastet, dass bei einem zu scharfen Timing eigentlich Fehler auftreten müssten... |
|
mulle78 |
Erstellt: 10:35 am 4. Dez. 2005 |
Ü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] |
|
mulle78 |
Erstellt: 14:01 am 25. Nov. 2005 |
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. |
|
mulle78 |
Erstellt: 16:34 am 24. Nov. 2005 |
Kopieen von HD 2 auf sich selbst am sekundären IDE Controller ebenfalls fehlerhaft:
990 Kopiervorgänge und 5 Fehler
0111AC3A: FF F7
037B95AA: 28 20
072D55AA: 88 80
07ED85AA: 4E 46
0C24E5AA: FF F7
|
|
Marauder25 |
Erstellt: 14:38 am 24. Nov. 2005 |
Ja das wäre ne Möglichkeit.
Ich erinner mich zwar an etwas, aber kann auch unwichtig sein.
Als ich mir meinen Athlon XP 2400+ gekauft habe damals, habe ich ihn zuerst auf einem Epox Board gehabt, da dieses aber beim kopieren auch andauernd Datenfehler produziert hat, bzw. auch einige Abstürze im Betrieb, hab ich es durch ein Gigabyte Board ersetzt.
Damals war das Problem mit dem Chipsatz 686B so massiv, das ganze Serien wieder zurückgerufen werden mussten.
Vielleicht wenn alle Stricke reissen, mal das Board tauschen.
Evtl. liegt wirklich ein Defekt am Board bzw. an der North/Southbridge vor.
Mike |
|
mulle78 |
Erstellt: 13:49 am 24. Nov. 2005 |
ja ich benutze Rundkabel. Die waren bis dato mit den Platten auf meinem A7S333 im Einsatz und dort gab es defenitiv keine Fehler, weil dies das Nachvolgesystem des KT133A war und ich dort den Test bei Einführung mit dem Kopieren und Vergleichen gemacht habe.
Ich habe aber vor, die Kabel durch andere zu ersetzen, die beim Maimboard origianl dbei waren.
(Geändert von mulle78 um 13:49 am Nov. 24, 2005) |
|
Marauder25 |
Erstellt: 12:56 am 24. Nov. 2005 |
Du benutzt wahrscheinlich IDE Rundkabel, oder?
Dieser Fehler kann dort nämlich auftreten, wenn die Adern "unsauber" aufgeteilt wurden. Tausch doch mal das Kabel gegen ein Standard Flachband Kabel aus.
Mike |
|
mulle78 |
Erstellt: 10:30 am 24. Nov. 2005 |
den RAM hab ich mal mit memtest86 über Nacht geprüft und 0 Fehler... wie aussagekräftig das auch immer ist.
Netzteilprobleme möchte ich auch ausschließen, da die Spannungen laut BIOS und MBM im Ramen sind. Auch habe ich keine Anzeichen für zu schwache Spannungsversorgung bemerkt.
Zur Zeit teste ich das Kopieren auf einem Kanal, also auf die gleiche Platte ... vielleicht passiert es ja nur, wenn ich von Kanal a auf b kopiere...
Ferner bekomme ich nächste Woche meine erste SATA Platte... mal sehen wie sie sich verhält in dem System und von SATA auf IDE kopieren, was dabei raus kommt. |
|
hax0r |
Erstellt: 9:10 am 24. Nov. 2005 |
Zitat von X1ALPHA um 8:26 am Nov. 24, 2005
Ram "im Arsch"!
|
Im Betrieb sind mir keine Stabilitätsprobleme aufgefallen. Prime95 rechnete nach meinem Übertakten Nächtelang ohne Fehler.
|
Ich schätze mal, wenn der RAM nen Knacks hätte, wären deutlich mehr Fehler zu sehen als 4 Bitfehler bei ~1300 Kopiervorgängen.
Haste mal Kabel, Festplatten, evtl. auch NT geprüft? |
|
X1ALPHA |
Erstellt: 8:26 am 24. Nov. 2005 |
| Ram "im Arsch"! |
![]() × |
