Benchmarking 1
TeamViewer Motive 3

[RAID0]CRC-Fehler bei großen Archiven sowie gelegentliche BSoDs

minux

Ensign
Registriert
März 2008
Beiträge
191
Hi!

Ich habe ein Problem, dass mich zunehmend stört.
Vor ungefähr 8 Wochen habe ich mir zwei neue 1TB (WD1001FALS) zugelegt und als RAID0-Array angelegt und eine normale (nicht Schnellformatierung) Formatierung durchgeführt. Lief alles wie geschmiert und auch augenscheinlich waren im Betrieb keine Fehler festzustellen bis ich bemerkt habe, dass auffällig viele der großen Archive, die ich bei rapidshare&co lade, CRC-Fehler haben. Habe das Anfangs auf eine missglückte Datenübertragung zurückgeführt.
Leider war dem nicht so, denn sobald ich selbst ein größeres Archiv ( ca 4GB>) erstelle und das probeweise wieder entpacke, werden mir bei jedem weiteren Versuch CRC-Fehler in den unterschiedlichsten Archivteilen gemeldet.
Um Fehler mit dem Arbeitsspeicher ausschließen zu können, habe ich memtest bereits 6 mal für jeden Riegel durchlaufen lassen. Es wurden keine Fehler gefunden. Auch die Kabel sitzen alle richtig; uU könnte ich da mal mit verschiedenen Kabelkombinationen rumexpermimentieren.
Erstelle ich nun Archive in besagter Größer auf einer anderen meiner Festplatten, die in kein RAID-Array eingebunden ist und auch einen anderen Controller benutzt, entstehen keine CRC-Fehler.
Durch die unternommene langwierige aber erfolgreiche Formatierung wähne ich mich sicher vor einem Festplattenschaden ( werde ich verifizieren durch WDs eigenes Diagnoseprogramm ).
Ach und alle Jahre wieder schmiert mein System ab mit einem BSoD, der variierende Fehlermeldungen enthält:
"Fatal System Error blabla"
"Hardware Maschine Exception"
.
.
.
Ich bin schlichtweg mit meinem Latein am Ende und benötige dringend frischen technischen Input zu der Problemstellung.
Danke !
 
Stell den Ramm mal besser ein, meist liegen CRC Fehler am Ram. Kannst es ja ml mit nur 2 GB versuchen ob es dann geht. Hast Du OC?
Oder Du hast Probleme mit den 2 TB im Raid 0, evtl verträgt es der Controller nicht.
 
Du meinst am Arbeitspeicher/RAM ?
Wie bereits beschrieben, habe ich den RAM ausführlich mit memtest Riegel für Riegel fehlerfrei getestet.
Was genau sollte ich denn am RAM besser einstellen ?

Nein z.Z. laufen alle Systemkomponenten mit Ihrer vorgeschriebenen Taktung/Spannung.

Der RAID-Controller sollte das schon vertragen. Dafür ist er ja ausgelegt. Ob es wohl möglich wäre das BIOS des RAID-Controllers zu flashen; die Frage habe ich mir schon gestellt. Leider habe ich dazu nichts gefunden.
Ich vermute aber, dass der Teil integraler Bestand meines Mainboard-BIOS sein wird und obwohl es eine neues (Beta-)BIOS dafür gibt, implementiert das wohl nur neue (CPU-)Steppings.
 
CL5 ist eingestellt? Ist es ein Onboard Controller wird er nur mit dem Bios upgedatet.
Du schreibst aber doch, das es bei den anderen Platten keine Probleme gibt, dann kann es ja nur an den Platten oder am zu grossen Raid liegen und wohl weniger an dem Ram.
 
CL5 ist eingestellt.
Ja der Controller ist onBoard.
Wollen wir mal davon ausgehen, dass die Festplatten in Ordnung sind.
Aber ein zu großes Raid? Wirklich? Davon habe ich bisher noch nichts gehört. Ist das ein bekanntes Problem ?
 
Weiss ja nicht ob beim Bau des Boards schon daran gedacht wurde, das es mal Platten gibt die mehr als 500 GB haben und deshalb evtl auch nur 1TB im Raid unterstützt werden, dazu müsstest Du mal den Support vom Hersteller anschreiben/befragen. Es gibt viele Controller die z.B. nur Platten bis zu einer bestimmten Grösse verwalten können.
 
Da es mit anderen Disk an einem anderen Controller läuft, gehe ich mal zunächst nicht von einem Speicherfehler aus. Allerdings ein aussagekräftiger Speichertest inkl. 'walking bit pattern' würde Tage dauern, was Du sicher nicht gemacht hast.

Da man keine sinnvollen Tests mit Disks im RAID machen kannst, solltest Du sie als Single Drive an einem anderen Controller testen (be. S.M.A.R.T.). Ein ausgiebiges Format gibt nur den zu dem Zeitpunkt ermittelten Gesundheitszustand wieder und bedeutet in keinster Weise, dass die Disk nicht ein paar Minuten später über den Jordan geht, insofern ist ein langes Format absolut sinnlos!

CRC-Fehler können an der Disk liegen, an der Datenübertragung zur Disk und am Controller inkl. Treiber. Erste Hinweise könnten wie oben aufgeführt die S.M.A.R.T.-Werte ergeben.

Zu den BSOD's, hier wären die Stop-Codes entscheidend, aber es sollten eigentlich Mini-Speicherabzüge im Windows-Verzeichnis unter Minidump zu finden sein. Mit dem WinDbg und den Symbols kann man dort die Informationen auslesen, wenn Du es nicht selber kannst, könntest Du die Minidumps hochladen!
 
Die Platten werden doch wohl alle am selben Controller hängen, SATA 2 Platten im Raid, die anderen normal?
 
Ich hatte nicht erwähnt, dass meine Auslagerungsdatei komplett deaktiviert war, denn mit 4GB bzw 8GB RAM ( Einer der 4 Riegel (2x4GBKit) aus einem der Kits war nämlich defekt und ist zZ noch RMA) wäre es ja eigentlich angebracht nur den RAM zu benutzen. Um aber ein minidump zu erhalten, braucht man schließlich eine Auslagerungsdatei. Also habe ich eine eingerichtet auf der Festplatte, auf der auch die Archive ohne Fehler entpackt werden.
Komischerweise habe ich seitdem keinen einzigen BSoD gehabt, obwohl ich den PC intensiv benutzt habe. Davor haben sich die BSoDs bis zu einer 30 minütigen Frequenz erhöht; sowohl auf dem Desktop als auch im Spielebetrieb.
Wofür spricht das jetzt? Mit der pagefile wird der RAM vermutlich entlastet und eine potentiell fehlerhafte Stelle mit einer entsprechend kleineren Wahrscheinlichkeit beschrieben?
Oder Windows XP x64 gefällt die Tatsache nicht, dass die Auslagerungsdatei komplett im RAM liegt ?

Mueli schrieb:
Da es mit anderen Disk an einem anderen Controller läuft, gehe ich mal zunächst nicht von einem Speicherfehler aus. Allerdings ein aussagekräftiger Speichertest inkl. 'walking bit pattern' würde Tage dauern, was Du sicher nicht gemacht hast.

Nein einen 'walking bit pattern' habe ich nicht durchgeführt. Führt memtest das per default durch bzw ist nach richtiger Einstellung in der Lage dazu?
Der letzte RAM-Test liegt mittlerweile auch knapp 4 Wochen zurück. Da habe ich auch den 1 fehlerhaften Riegel entdeckt. Der PC hat mit dem Riegel alleine gar nicht erst gebootet.
Ich habe seit dem der RAID-Fehler/die BSoDs aufgetreten sind auch keinen Weiteren mehr durchgeführt in der Annahme, dass die Wahrscheinlichkeit für einen weiteren defekten Speicherriegel gegen 0 geht. Vermutlich sollte ich da nochmal ansetzen.

Mueli schrieb:
Da man keine sinnvollen Tests mit Disks im RAID machen kannst, solltest Du sie als Single Drive an einem anderen Controller testen (be. S.M.A.R.T.). Ein ausgiebiges Format gibt nur den zu dem Zeitpunkt ermittelten Gesundheitszustand wieder und bedeutet in keinster Weise, dass die Disk nicht ein paar Minuten später über den Jordan geht, insofern ist ein langes Format absolut sinnlos!

Mir wird nur Angst und Bange bei dem Gedanken, dass mein beinahe vollkommen ausgelastetes RAID-Array ( von den nominellen 1.81TB sind bereits 1.685TB belegt ) bei der Diagnose mit WDs eigener low-level Software in Mitleidenschaft gezogen wird. Schließlich meine ich mich an eine Warnung erinnern zu können, dass selbst der Read-Only Test zu (irreparablen) Beschädigungen der Datenintegrität führen kann (oder war das Samsung ?). Natürlich wäre ein Backup möglich, aber dazu müsste ich die gespeicherten Inhalte über mehrere Laufwerke aufwendig verteilen. Das sollte eine der Optionen sein, die ganz unten auf der Liste der möglichen Diagnoseverfahren steht.

Mueli schrieb:
Zu den BSOD's, hier wären die Stop-Codes entscheidend, aber es sollten eigentlich Mini-Speicherabzüge im Windows-Verzeichnis unter Minidump zu finden sein. Mit dem WinDbg und den Symbols kann man dort die Informationen auslesen, wenn Du es nicht selber kannst, könntest Du die Minidumps hochladen!

Tja der berühmte Vorführeffekt... :(
Dann wenn man sich den Blauen wünscht, ist weit und breit nichts davon zu sehen.
Sollte er dennoch unverhofft bzw unglücklicherweise auftreten, werd ich das minidump debuggen und hier präsentieren.

werkam schrieb:
Die Platten werden doch wohl alle am selben Controller hängen, SATA 2 Platten im Raid, die anderen normal?
Auf dem Board sind 8 SATA-Ports. 6 davon sind in einer Einheit und die zwei Weiteren auch in einem eigenen Block.
Dazu hier ein Bild:


ROTES QUADRAT: RAID0-Array
GELBES QUADRAT: Die restlichen HDDs im non-Raid Modus sowie mein DVD-Brenner

Um die Wahrheit zu sagen, ich weiß nicht, ob wir es hier mit zwei verschiedenen Controllern zu tun haben, aber ich bin mir fast sicher das.
Man beachte aber, dass beide Blöcke RAID-fähig sind. Der gelbe Block bietet zusätzlich optional noch AHCI/IDE was man im Bios festlegen kann.


Noch irgendwelche Vorschläge ? Bin für jede Hilfe dankbar und natürlich auch schon für die bereits eingegangen Hilfestellungen... ;) !
 
Zuletzt bearbeitet: (additional information added)
Da ist aber noch Luft, auch wenn nicht mehr viel.
Nimmt man die untere Grenze von 5%, dann sollte der freie Speicher nicht unter 90.5GB fallen und davon bin ich noch ein gutes Stück entfernt.
Übrigens benutzte ich Diskeeper zur Life-Defragmentation. Dabei kommt eine sogenannte 'I-FAAST'-Technologie zum Einsatz:
Code:
This feature is only available for NTFS volumes. FAT volumes are not supported. Intelligent File Access Acceleration Sequencing Technology (I-FAAST) improves file access and creation on NTFS volumes by up to 80% (average 10%-20%) above and beyond the improvement provided by defragmentation alone. This is the first industry implementation of “Disk Performance Calibration”, the modern evolution of the outdated and inconclusive disk optimization strategies of the past. Automatic Defragmentation keeps your volumes running as if they were new. I-FAAST Defragmentation works alongside Automatic Defragmentation to improve performance of your volumes to better than new.
[...]
When I-FAAST Defragmentation is enabled on a volume, Diskeeper runs specially-engineered benchmarks on the selected NTFS volumes to learn their individual performance characteristics. (Not all disks have the same characteristics.) Diskeeper then transparently monitors these volumes for file access frequency on an ongoing basis in to determine which files are requested most often. Special analysis techniques prevent Diskeeper from being "fooled" by files that have been recently accessed. 

Using newly-developed technology, Diskeeper sequences the files to take best advantage of both the logical characteristics and physical characteristics of the volume. The sequencing process is integrated with Automatic Defragmentation, so it’s virtually transparent to you. 
[...]
Also note that in the course of processing the files on the volume for best performance, I-FAAST will at times temporarily fragment one or more files. The fragmented state is only temporary and is only done in cases where it will be beneficial to the performance of the files on the volume.

I-FAAST intelligence allows Diskeeper to adapt to changing situations—so if the demands on a given system change, Diskeeper automatically adjusts its behavior accordingly.

In der Anleitung steht auch, dass es durch die erhöhte HDD-Aktivität zu gehäuften Fehlern kommen kann und man regelmäßig chkdsk laufen lassen sollte.
Ich denke das werde ich mal ausprobieren.
Gleich wieder da... ;)
 
Nimmt man aber die obere Grenze von 20% wird es schon sehr eng. Liegt ja auch immer daran wie gross die Dateien sind und wie gross die Clustergrösse ist.
 
Ich werde mal ein paar viele GB auslagern um den 20% etwas näher zu kommen. Vielleicht hilft das ja auch...

chkdsk ist durchgelaufen und hat Fehler festgestellt.
Jetzt wollte ich überprüfen, ob die CRC-Fehler immer noch auftreten.
Dummerweise hat sich der Laser meines Wohnheims ab- und die Funk-Backupstrecke dazugeschaltet.
Das bedeutet nur ca. 1.5 MB/s und nicht die üblichen 11.5MB/s sind möglich. Mit der Geschwindigkeit werde ich aber kein 10GB Archiv zum Testen laden. Ich melde mich dann morgen nochmal mit Neuigkeiten, sobald sich der Nebel im wahrsten Sinne des Wortes gelichtet hat...optischer Richtfunk ist schon was Geiles... :freak:
 
Der letzte Memtest86 ist bei mir schon eine Weile her, wenn ich mich recht entsinne musste man die Testmodule konfigurieren und per Default wurde nur ein bestimmter teil ausgeführt. Ich denke dies Testtool wird auch Walking Bit Pattern nutzen können, weil damit ein 'übersprechen' einzelner Zellen, Rows und Columns erfasst wird, sonst mach ein Speichertest auch keinen wirklichen Sinn. Auf UNIX Servern musste man sowas jedenfalls immer explizit einschalten, weil derartige Tests das System immer recht umfangreich ausbremsten. Da Memtest aber ein Offline Test ist (einen Server kann man nicht aus dem Verkehr ziehen, um den Speicher zu testen) wäre es nicht nötig, aber wer will seinen PC schon für Tage aus dem Verkehr ziehen?! :D

Ohne Auslagerungsdatei zu arbeiten ist keine gute Idee, weil dieser Mechanismus fest im Windows verankert ist und man NT damit schon etwas irritiert, ich habe auch schon einen Test gesehen, wobei ohne konfigurierte Auslagerungsdatei das System ausgebremst wurde.

Ein Download eignet sich nicht wirklich um CRC-Fehlern aus die Spur zu kommen, dabei sind einfach zu viele Subsysteme (Netzwerk-Treiber, Chipset-Treiber, Mass-Storage-Treiber etc.) beteiligt.

Was CRC-Fehler bezüglich des Mass-Storage-Subsystems angehen, kann man im S.M.A.R.T.-Log schon die Übertragung Controller <-> Disk und Drive-Electronic (Read-Write-Logic) <-> Platter (Media) in den Attributen ablesen und da war bei Dir nichts gravierendes zu sehen.

Wenn das Filesystem Fehler hat, kann es allein schon dadurch kommen, dass ein OS vermehrt abstürzt.

Tests sollten immer speziell auf einen Teil der Hardware ausgeführt werden, z. B. mit NetIO zwischen zwei PC's (einer ist dazu in den Servermode zu versetzen). Vom Heise-Verlag (c't) gibt es einen Test der speziell die Disk testet (mir fällt im Moment der Name nicht ein, findest Du aber dort unter den Downloads).
 
Ich hatte an mehreren Stellen gelesen, dass das Abschalten der Auslagerungsdatei bei ausreichend vorhandenem Speicher kein Problem darstellt. Nun die Realität hat mich mal wieder eines Besseren belehrt.
Immer noch keinen BSoD gehabt.
Werde den RAM-Test aber nach Weihnachten nachholen um auch wirklich auf Nummer sicher zu gehen.
Auf dein Anraten habe ich mir mal WDs Diagnostik für Windows runtergeladen um den SMART-Status abzurufen. Natürlich erkennt der mein RAID-Array nicht. Wenn ich das Array löschen würde, könnte ich es im Nachhinein wieder ohne Weiteres wiederherstellen? Ansonsten mach ich das per bootablem USB-Stick oder Ähnlichem und klemm die beiden RAID-Platten an meinen anderen SATA-Block. Können dabei Daten verloren gehen? Ich bin leider doch sehr unerfahren in Sachen RAID.

Mein OS liegt nicht auf dem RAID. Ich benutze das als sehr effiziente Möglichkeit Daten aus dem Internet runterzuladen (man beachte wir haben eine 100Mbit Internetanbindung mit der ich auf ca 11.5Mb/s UP/DOWN komme[ ich kanns nicht oft genug sagen :)]), zu entpacken und im Studentenwohnheim internen DC-HUB zu sharen. Das alles gleichzeitg schafft eine HDD alleine nicht. Außerdem hatte ich das Gefühl, das mit dem Auslagern der Auslagerungsdatei in den RAM der größte "Perfomanceflaschenhals" eliminiert wurde. Dabei lasse ich den Bootvorgang außer Acht.
 
Zuletzt bearbeitet:
Ich würde das RAID nicht auflösen, sondern besser ungenutzte SATA-Ports die nicht im RAID laufen, nutzen. Via UBCD und / oder INSERT könnte man auch unabhängig vom installierten System die Diagnose durchführen.
 
Guten Morgen!

Ich habe mich am Debuggen versucht, leider jedoch erfolglos.
Falls also jemand in der Lage ist, sich die Minidumps genauer anzuschauen bzw entsprechend aufzuschlüsseln, wäre mir das sehr willkommen. ;)
 

Anhänge

Unable to load image ati2cqag.dll, Win32 error 2
*** WARNING: Unable to verify timestamp for ati2cqag.dll
*** ERROR: Module load completed but symbols could not be loaded for ati2cqag.dll
Unable to load image ati2mtag.sys, Win32 error 2
*** WARNING: Unable to verify timestamp for ati2mtag.sys
*** ERROR: Module load completed but symbols could not be loaded for ati2mtag.sys
Probably caused by : ati2cqag.dll ( ati2cqag+47a34 )
Probably caused by : ati3duag.dll ( ati3duag+23a379 )

Du hast wohl Probleme mit den ATI-Treibern?
 
Das nimmt sich wohl ganz so aus.
Hast du alles dumps ausgelesen ?
Habs mittlerweile auch geschafft den debugger zu installieren.
Also ich hatte zwischenzeitlich auch eine GTX 280 drinnen und dabei ist dieses dump rumgekommen:

Code:
Unable to load image ha20x2k.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ha20x2k.sys
*** ERROR: Module load completed but symbols could not be loaded for ha20x2k.sys
*** WARNING: Unable to verify timestamp for emupia2k.sys
*** ERROR: Module load completed but symbols could not be loaded for emupia2k.sys
Unable to load image ks.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ks.sys
Unable to load image portcls.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for portcls.sys
Unable to load image ctaud2k.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ctaud2k.sys
*** ERROR: Module load completed but symbols could not be loaded for ctaud2k.sys
Unable to load image ksthunk.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ksthunk.sys
Unable to load image sysaudio.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for sysaudio.sys
Probably caused by : ha20x2k.sys ( ha20x2k+e47d2 )

Offenbar ein Problem mit der Soundkarte. Ich hab aber meine IRQs gecheckt und da sind zwar viele Überschneidungen drinnen, die ich aber nicht ändern könnte. Höchstens die Soundkarte einen Steckplatz höher oder tiefer.
 
Da würde ich mal eine Neuinstallation machen, stell im Bios P&P OS auf enabled, dann hast Du auch keine Probleme mit der IRQ Verteilung, ACPI/APIC sollte auch aktiv sein. Und Treiber für X 64 solltest Du benutzen, da stehen viele Fehler mit win 32?
Und verschiedene Grafikkarten (Ati/Nvidia) zu benutzen ohne die alten Treiber komplett zu löschen ist auch nicht der Bringer.
 

Ähnliche Themen

Zurück
Oben