Mittlerweile kann ich ruhigen Gewissens behaupten, dass mein neues System stabil läuft. Die neue Festplatte macht keinen Ärger mehr – naja, so gut wie keinen. Wenn ich die Festplattenlast massiv erhöhe, z.B. Backup mache, iTunes öffne (offensichtlich sucht er dann erstmal, ob alle Dateien noch da sind) und dann noch einen Kopiervorgang starte, dann bleibt manchmal das gesamte System stehen. Nach ca. 1 Minute geht es weiter, als wäre nie etwas geschehen. Ein Blick in die Ereignisanzeige von Windows offenbart im Systemprotokoll folgenden Fehler: Ein Zurücksetzen auf Gerät \Device\RaidPort0 wurde ausgegeben. Vielleicht ist noch die Ereignis-ID 129 wichtig, das weiß ich nicht.
Man sollte sich erstmal nicht vom Offensichtlichen täuschen lassen – mit RAID hat der Fehler wohl garnichts zu tun. Ich habe bei mir kein RAID zu laufen. Aber am besten fange ich erstmal mit der Event-ID 129 an. Im Grunde genommen wird die Dateianfrage durch die ganzen Schichten reicht, bis sie beim Festplattentreiber ankommt, der dann den Zugriff auslöst. Gleichzeitig wird ein Timer gestartet. Im Normalfall läuft der Timer nie aus, weil die Antwort schnell genug da ist. Wer nachschauen möchte, findet den Wert in der Registry unter HKLM/SYSTEM/CurrentControlSet/services/Disk unter dem Wert „TimeOutValue“. Bei mir steht da 60 drin, was der gefühlten Minute, bis das System weiterarbeitet, entspricht. Warum auch immer kommt an diese Stelle keine Antwort von der Festplatte und Windows löst einen Reset (klingt besser wie „Zurücksetzen“) für das Gerät aus. Soweit beschreibt Microsoft den Fehler, aber das hilft mir immer noch nicht weiter…
AHCI-Powermanagement
Wie so oft – wenn man eine Lösung kennt und danach sucht, findet man alle, die das Problem auch haben. Übeltäter ist das AHCI – wir erinnern uns: AHCI ist eine Schnittstelle für SATA-Controller. Die bringt auch ihr eigenes Power Management mit sich. Ich hatte zu Beginn ja den Verdacht, dass es am Board liegt oder an der Platte – nein, wenn man im Internet sucht findet man sämtliche Prozessoren, Boards und Platten. Gehen wir aber etwas weiter in die Tiefe – das AHCI kommt aus dem Hause intel und unterscheidet beim Power Management für SATA-Platten zwischen HIPM (Host Initiated Link Power Management) und DIPM (Device Initiated Link Power Management). Klingt aufregend und kompliziert, heißt aber nichts anderes wie: Das Betriebssystem entscheidet, wann die Platte in Energiesparmodus geht (HIPM) oder die Platte entscheidet selbst (DIPM) oder beide gemeinsam (HIPM+DIPM).
Nach meinen ganzen Recherchen konnte ich nicht wirklich herausfinden, warum jetzt das System hängen bleibt, sondern habe nur die Abhilfe dafür gefunden. Dazu muss man sich wieder ander Registry vergreifen. Dort gibt es unter HKLM/SYSTEM/CurrentControlSet/Control/Power/PowerSettings/0012ee47-9041-4b5d-9b77-535fba8b1442/0b2d69d7-a2a1-449c-9680-f91c70521c60 den Wert für „Attributes“ von „0x00000001“ auf „0x00000002“. Wunder oh Wunder, jetzt erscheint in den erweiterten Energieoptionen im Bereich „Festplatte“ eine neue Auswahl, wo sich aussuchen kann, wer entscheiden darf, wann die Platte in Energiesparmodus geht.
Jetzt folgt die Phase, wo ich probieren muss, welche Einstellung das Problem behebt.
- HIPM+DIPM: keine halbe Stunde und das System blieb wieder hängen.
- Active: heißt eigentlich – keiner schläft. 12:04 Uhr – Ein Zurücksetzen…
- HIPM: das war der Standardwert, nachdem ich in der Registry geändert hatte. 14:50 und 16:40 Uhr – in meiner Abwesenheit: Ein Zurücksetzen…
- DIPM: Letzte Einstellmöglichkeit, mal sehen wie das System reagiert, wenn die Platte selbst entscheiden darf. 17:44 Uhr… Der war es dann wohl auch nicht.
Standard-SATA-Treiber
Eine wiederholte Suche nach der Ereignis-ID 129 brachte mich zu einer Seite, die vorschlug, dass man den AMD-SATA-Controller-Treiber durch den Standard-Microsoft-Treiber auszutauschen. Dazu geht man in den Gerätemanager und in der Sektion „IDE ATA/ATAPI-Controller“ findet man den AMD SATA Controller. Ein Rechtsklick ermöglicht die Treiberaktualisierung. Da der Treiber von Microsoft schon mit installiert ist, wählt man „Auf dem Computer nach Treibersoftware suchen“ aus, geht dann auf „Aus einer Liste von Gerätetreibern auf dem Computer auswählen“ und pickt sich dort den Microsoft-Standard-Treiber raus. Rechner neu gestartet und nun…
Ich beginne einfach etwas Last zu erzeugen, indem ich eine große Datei von einer Partition auf eine andere kopiere – beide liegen auf der gleichen physischen Festplatte. Ruckzuck füllt sich das Fehlerprotokoll von Windows mit den ATAPI-Fehlern, die mich schon zum Wahnsinn getrieben haben. Dieser Versuch wird auch als nicht erfolgreich abgehakt, ich bin ganz schnell wieder zum ursprünglichen Treiber zurückgewechselt.
Treiberupdate
Ich hätte schwören können, dass ich das schon gemacht habe, als ich den Rechner neu installiert habe. Aber man weiß ja nie. Ich warf einen Blick auf die Webseite von Gigabyte und suchte explizit nach einem AHCI-Treiber und wurde nicht enttäuscht. Wahrscheinlich habe ich bei der Neuinstallation das komplette Treiberpaket heruntergeladen (Stand: 8/2012), aber jetzt nur den AHCI-Treiber (Stand 1/2014). Wie man den Treiber austauscht, habe ich ja gerade schon beschrieben. Bis jetzt ist der Eintrag nicht wieder im Protokoll aufgetaucht. Mal sehen, was passiert, wenn morgen wieder das Backup ansteht…
Nachtrag 17.05.2015
Das Treiberupdate hat wirklich Verbesserung gebracht. Ich habe mal das Ereignisprotokoll befragt und seit dem ich diesen Beitrag geschrieben habe, ist der Fehler 16 mal wieder aufgetreten. Klingt jetzt wirklich viel, aber auf ein halbes Jahr gerechnet ist das 2-3 mal im Monat. Gefühlt hätte ich jetzt insgesamt vielleicht 6 mal gesagt. Es scheint also auch zu passieren, wenn ich nicht aktiv am Rechner arbeite.
