nForce 4 gleiche Probleme wie KT133A??? Binärfehler!!!
- Ersteller mulle78
- Erstellt am
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:
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?!
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?!
Mac_Fly
Captain Special
Probier das Ganze zunächst mal mit deutlich entschärften Ram-Timings, etwa 10-3-3-3 (und natürlich Referenztakt und den ganzen hokuspokus alles auf standard, gar nichts übertakten, auch nicht die cpu) .. vielleicht hilft das schon den Fehler einzugrenzen... ansonsten könnte es länger dauern. Dann müssteste wahrscheinlich erstmal bis aufs letzte Käbelchen alles durchtauschen und checken..
Achja, ganz wichtig, und steck die Platten mal zusammen an einen Strang und die optischen Laufwerke zusammen an den anderen (und ich erwähne es mal ganz vorsichtig: auf Master/Slave-Jumperung achten); gibt genug Fälle, wo sich HDD und optisches Laufwerk beissen, schon allein wegen unterschiedlicher DMA-Modi auf demselben Kanal.
Gruesse / Mac_Fly
Achja, ganz wichtig, und steck die Platten mal zusammen an einen Strang und die optischen Laufwerke zusammen an den anderen (und ich erwähne es mal ganz vorsichtig: auf Master/Slave-Jumperung achten); gibt genug Fälle, wo sich HDD und optisches Laufwerk beissen, schon allein wegen unterschiedlicher DMA-Modi auf demselben Kanal.
Gruesse / Mac_Fly
Zuletzt bearbeitet:
wie im nachgereichten Post geschrieben, das Probelm tritt auch bei Standardtackt auf!!! RAM ist mit memtest86 geprüft... die Timings kann ich aber noch entschärfen/sind allerdings keine scharfen Timings... Kabel habe ich ebenfalls vor zu tauschen.
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.
Die Platten und optischen Laufwerke waren eigentlich bewusst so gewählt, damit ich parallel brennen kann. Bei meinem vorherigen SiS Chipsatz hat das alles nur in dieser Konstellation funktioniert, da sonst der BUS eingebrochen ist. Das hat dort keine keine Probleme gemacht und die Kabel und Hardware wurde auf das neue Board übernommen. Das parallele Brennen funktioniert bei dem neuen Chipsatz auch, aber leider nur mit MS Treibern.
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.
Die Platten und optischen Laufwerke waren eigentlich bewusst so gewählt, damit ich parallel brennen kann. Bei meinem vorherigen SiS Chipsatz hat das alles nur in dieser Konstellation funktioniert, da sonst der BUS eingebrochen ist. Das hat dort keine keine Probleme gemacht und die Kabel und Hardware wurde auf das neue Board übernommen. Das parallele Brennen funktioniert bei dem neuen Chipsatz auch, aber leider nur mit MS Treibern.
blaundblub
Lieutnant
- Mitglied seit
- 30.07.2005
- Beiträge
- 52
- Renomée
- 0
Hi!
ich glaube dies sind die gleichen Probleme:
http://forums.nvidia.com/index.php?showtopic=8171
greetz
ich glaube dies sind die gleichen Probleme:
http://forums.nvidia.com/index.php?showtopic=8171
greetz
SND-Syndrome
Vice Admiral Special
- Mitglied seit
- 07.03.2005
- Beiträge
- 752
- Renomée
- 2
Welche Festplatten (welcher Hersteller) hast Du denn?
Luzypher
Grand Admiral Special
Hi folks!
Setz mal den Speichertakt von 195 MHz auf 166 MHz (DDR333).
cu ...
Luzy
Setz mal den Speichertakt von 195 MHz auf 166 MHz (DDR333).
cu ...
Luzy
SND-Syndrome
Vice Admiral Special
- Mitglied seit
- 07.03.2005
- Beiträge
- 752
- Renomée
- 2
Ok.
Habe mal gelesen, dass es zu diversen Problemen mit Maxtor-Platten gekommen sei...an bekannte Probleme mit WDs kann ich mich jetzt nicht erinnern
. Naja, war ein Versuch wer
Luzypher
Grand Admiral Special
Hi folks!
Das Problem ist wohl schon länger bekannt. Es dürfte ein Designfehler des Chipsets sein, der sich unter Last bei IDE/Speicher-Transfers in Form von Datenfehlern bemerkbar macht. Als "Fix" wird eben angegeben, daß man den Speichertakt unter Last von 200 MHz (DDR400) auf 166 MHz (DDR333) reduzieren soll. U.a. ist dieser Workaround Bestandteil der aktuellen BIOS-Versionen für die Asus A8N-Serie.
Also: einfach ausprobieren, testen, schauen obs klappt.
cu ...
Luzy
Das Problem ist wohl schon länger bekannt. Es dürfte ein Designfehler des Chipsets sein, der sich unter Last bei IDE/Speicher-Transfers in Form von Datenfehlern bemerkbar macht. Als "Fix" wird eben angegeben, daß man den Speichertakt unter Last von 200 MHz (DDR400) auf 166 MHz (DDR333) reduzieren soll. U.a. ist dieser Workaround Bestandteil der aktuellen BIOS-Versionen für die Asus A8N-Serie.
Also: einfach ausprobieren, testen, schauen obs klappt.
cu ...
Luzy
Luzypher
Grand Admiral Special
Hi folks!
cu ...
Luzy
Jupp, so siehts aus.
cu ...
Luzy
Also wenn ich das jetzt richtig verstehe.
Passiert dieser Fehler nur, wenn man normal IDE verwendet oder etwa auch bei S-ATA ?
Was mich interessieren würde ist, da ich ja nur S-ATA Platten verwende, ob ich auch mit Fehlern beim Brennen rechnen muss. Schließlich läuft mein DVD Brenner am IDE Kanal.
Passiert dieser Fehler nur, wenn man normal IDE verwendet oder etwa auch bei S-ATA ?
Was mich interessieren würde ist, da ich ja nur S-ATA Platten verwende, ob ich auch mit Fehlern beim Brennen rechnen muss. Schließlich läuft mein DVD Brenner am IDE Kanal.
Luzypher
Grand Admiral Special
Hi folks!
Das bezieht sich auf natives IDE und natives S-ATA, sowie auch komischerweise auf den meistens verbauten Silicon Image S-ATA per PCI. Zusatzkarten per PCI sind wohl nicht betroffen.
cu ...
Luzy
Das bezieht sich auf natives IDE und natives S-ATA, sowie auch komischerweise auf den meistens verbauten Silicon Image S-ATA per PCI. Zusatzkarten per PCI sind wohl nicht betroffen.
cu ...
Luzy
nachdem gestern am primären Controller mit der 160 GB bei 330 Kopien kein Fehler passierte habe ich über Nacht mal parallel auf dem primären Kanal auf sich selbst kopiert und auf dem sekundären Kanal auf der 250 GB HDD auf sich selbst kopiert.
Vorher habe ich noch das Kabel am sekundären Kanal getauscht. Da die 160 GB Platte noch nebenbei Systemplatte und etwas betagter ist, hat sie nicht ganz so viele Kopien geschafft.
994 Kopien am sekundären Controller auf der 250 GB HDD drei Kopierfehler
02CF25AA: 9A 92
05EE25AA: 8A 82
078865AA: 0E 06
514 Kopien am primären Kanal auf der 160 GB HDD ein Kopierfehler
049605AA: BC B4
Das könnte erklären, warum ich kein Probleme mit dem OS bemerkt habe, da es auf der betagteren Platte mit statistisch weniger Fehlern liegt. Hab jetzt auch nicht so viel getestet um festzustellen, ob der IDE Controller auf dem primären Controller nur spinnt, wenn auch am sekundären Controller massig Daten fließen.
Das erklärt auch manche Archive die dann ein zwei Dateien nicht entpacken konnten, weil sie defekt waren und defekte DVDs... eine zur Silberhochzeit von bekannten erstellte DVD machte auf Standalone Playern an einer Stelle Probleme und ich hab es auf das Bearbeitungsprogramm geschoben...
ich werde mal den Speichertakt senken und es noch einmal probieren.
Vorher habe ich noch das Kabel am sekundären Kanal getauscht. Da die 160 GB Platte noch nebenbei Systemplatte und etwas betagter ist, hat sie nicht ganz so viele Kopien geschafft.
994 Kopien am sekundären Controller auf der 250 GB HDD drei Kopierfehler
02CF25AA: 9A 92
05EE25AA: 8A 82
078865AA: 0E 06
514 Kopien am primären Kanal auf der 160 GB HDD ein Kopierfehler
049605AA: BC B4
Das könnte erklären, warum ich kein Probleme mit dem OS bemerkt habe, da es auf der betagteren Platte mit statistisch weniger Fehlern liegt. Hab jetzt auch nicht so viel getestet um festzustellen, ob der IDE Controller auf dem primären Controller nur spinnt, wenn auch am sekundären Controller massig Daten fließen.
Das erklärt auch manche Archive die dann ein zwei Dateien nicht entpacken konnten, weil sie defekt waren und defekte DVDs... eine zur Silberhochzeit von bekannten erstellte DVD machte auf Standalone Playern an einer Stelle Probleme und ich hab es auf das Bearbeitungsprogramm geschoben...
ich werde mal den Speichertakt senken und es noch einmal probieren.
Hmmm also solche Fehler dürften wirklich nicht passieren.
Wie kann man sowas auf die Menschheit loslassen. Normalerweise hätte es bei sowas eine Rückrufaktion geben müssen.
Es kann doch nicht sein, dass man den Speicher auf DDR 333 laufenlassen muss damit alles funzt. Wo bleibt da der performante Nutzen mit dem sonst geworben wird.
Laufen dadurch die FSBs nicht asynchron, das ist doch auch wieder nicht das gelbe vom Ei oder ?
Jetzt mal ne andere Frage kann es nicht auch möglich sein, dass der Ram oder der Cache einen knacks hat bzw. doch nicht so kompatibel ist wie er sein sollte ?
Weiß jemand ob dass auch bei den MCPs (neuen Sli) Mobos passiert ?
Schließlich haben die wieder eine North- und eine Southbridge somit dürfte die Last doch gar nicht mehr so an einem Chip hängen oder habe ich da was falsch verstanden ?
Dann warte ich wohl lieber noch eine weitere Generation ab.
Wie kann man sowas auf die Menschheit loslassen. Normalerweise hätte es bei sowas eine Rückrufaktion geben müssen.
Es kann doch nicht sein, dass man den Speicher auf DDR 333 laufenlassen muss damit alles funzt. Wo bleibt da der performante Nutzen mit dem sonst geworben wird.
Laufen dadurch die FSBs nicht asynchron, das ist doch auch wieder nicht das gelbe vom Ei oder ?
Jetzt mal ne andere Frage kann es nicht auch möglich sein, dass der Ram oder der Cache einen knacks hat bzw. doch nicht so kompatibel ist wie er sein sollte ?
Weiß jemand ob dass auch bei den MCPs (neuen Sli) Mobos passiert ?
Schließlich haben die wieder eine North- und eine Southbridge somit dürfte die Last doch gar nicht mehr so an einem Chip hängen oder habe ich da was falsch verstanden ?
Dann warte ich wohl lieber noch eine weitere Generation ab.
Zuletzt bearbeitet:
SND-Syndrome
Vice Admiral Special
- Mitglied seit
- 07.03.2005
- Beiträge
- 752
- Renomée
- 2
Also so wie ich es verstanden habe (lasse mich aber gerne eines Besseren belehren), ist beim neuen SLI x16 Chipsatz die "Southbridge" nur ein Zusatzchip, der die zusätzlichen PCIe-Lanes zur Verfügung stellt. Meiner Vorstellung nach ist demnach immer noch der jetzige nForce 4 SLI auf den neuen Boards verbaut, nur eben mit diesem Zusatzchip...somit dürfte das Problem - so es denn ein allgemeines ist und nicht nur bei der Konfiguration des Thread-Erstellers auftritt - weiterhin bestehen....
Hmm, ich sehe gerade du hast auch ein A8N Mobo.
Hast du selber schon was davon gemerkt ?
Denn meine erste Vermutung war dass der Speicher, den der Threadsteller eingebaut hat, vielleicht mit dem MOBO nicht 1A harmoniert. Ich sehe auch gerade das er DDR333 verbaut hat und nicht 400.
Hast du selber schon was davon gemerkt ?
Denn meine erste Vermutung war dass der Speicher, den der Threadsteller eingebaut hat, vielleicht mit dem MOBO nicht 1A harmoniert. Ich sehe auch gerade das er DDR333 verbaut hat und nicht 400.
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.
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.
SND-Syndrome
Vice Admiral Special
- Mitglied seit
- 07.03.2005
- Beiträge
- 752
- Renomée
- 2
Ja, habe auch das A8N-SLI Deluxe.
Bei mir treten trotz Vollbestückung des RAMs (4 Module/SingleSided @1t) keinerlei Probleme auf.
Wobei ich zugeben muss, dass ich bis jetzt noch keine Riesen-Dateien à la 5 Gig oder so kopiert habe und auch noch keine Dateien miteinander Verglichen habe.
Jedoch läuft alles einwandfrei und ohne Fehler. *freu*
SND-Syndrome
Vice Admiral Special
- Mitglied seit
- 07.03.2005
- Beiträge
- 752
- Renomée
- 2
Dann versuche mal, den RAM vollständig in den Spezifikationen zu betreiben, also 2,5-3-3-8. Vielleicht macht das schon den Unterschied...
Hmmm das habe ich auch gerade gedacht.
Sagt mal wie sieht das eigentlich aus. Wenn ich das technische richtig verstehe so ist der Memory Controller doch in der CPU integriert oder ?
Das komische ist nämlich das zwar einige diesew Probleme haben aber viele andere wiederum nicht.
Wäre es nicht möglich dass es auch an der CPU liegen könnte sprich dass der Memory-Controller sozusagen nicht ideal läuft ?
ICh habe mal Überlegungen angestellt. Könnte das nicht sogar an den nforce Treibern liegen ? In irgendweinem Forum stand da was von. Da wurde was von 6.66 gefaselt, dass diese einen Bug im SM-Controller hat. Aber ich finde das nicht mehr. Hmmm....
Sagt mal wie sieht das eigentlich aus. Wenn ich das technische richtig verstehe so ist der Memory Controller doch in der CPU integriert oder ?
Das komische ist nämlich das zwar einige diesew Probleme haben aber viele andere wiederum nicht.
Wäre es nicht möglich dass es auch an der CPU liegen könnte sprich dass der Memory-Controller sozusagen nicht ideal läuft ?
ICh habe mal Überlegungen angestellt. Könnte das nicht sogar an den nforce Treibern liegen ? In irgendweinem Forum stand da was von. Da wurde was von 6.66 gefaselt, dass diese einen Bug im SM-Controller hat. Aber ich finde das nicht mehr. Hmmm....
Zuletzt bearbeitet:
Ähnliche Themen
