S.M.A.R.T. Error beim Booten mit AHCI

julioo

Lt. Junior Grade
Registriert
Okt. 2010
Beiträge
316
Hi,

ich hab als Systemplatte eine neue SSD Platte eingerichtet und im Zuge dessen im BIOS den AHCI Modus eingestellt. Nach der Win7-Install. inkl. aller Programme habe ich das Problem, dass
- nach jedem Reboot der Bootvorgang an der Stelle hängen bleibt, wo die SATA-Platten aufgelistet werden. Dort bekomme ich dann bei einer Platte einen S.M.A.R.T. Error angezeigt (siehe angehängtes Bild). Seltsam ist aber, dass
- nach einem Kaltstart der PC normal bootet, insbes. der SMART Error nicht mehr angezeigt wird.

HD Tune Werte der Platte mit dem SMART Error habe ich ebenfalls als Bild beigefügt. Werte scheinen ok zu sein, oder? Error Scan ist grad bis zur Hälfte durch, bisher alles ok.


Woran kann es liegen, dass der Neustart Probleme macht, beim Kaltstart alles normal durchläuft?

Vielen Dank schon mal für Eure Hilfe!

PS:
Mainboard: Gigabyte GA-MA78GM-S2H (rev. 1.1)
 

Anhänge

  • IMAG0038.jpg
    IMAG0038.jpg
    270,9 KB · Aufrufe: 346
  • Unbenannt.JPG
    Unbenannt.JPG
    73,8 KB · Aufrufe: 237
die Frage wäre doch: hat die Platte jetzt einen Fehler oder nicht?
 
Benutzt du den MS AHCI Treiber oder hast du die AMD Treiber installiert?
Wenn vorhanden dann flashe auch die neueste Firmware in deine SSD und es kann auch nicht schaden das neueste BIOS deines Boards zu flashen, da hier auch oft neuere bugbefreite AHCI Firmware gleich mit installiert wird.

Im Gigabyte Forum gibts übrigens einen Thread mit dem selben Thema, schau mal da rein:
http://mbforum.gigabyte.de/index.php?page=Thread&postID=12194&highlight=GA-MA78GM-S2H#post12194

Hier gibts auch einen Link zu einem BIOS das eine neue AHCI Firmware enthält, probiere das unbedingt aus da es wohl dein Problem lösen kann!
Auch wen das BIOS u.U. alter ist kann es sein das neuere BIOSe diese AHCI Firmware nicht enthält, daher ruhig zuerst mal das neueste F12B testen, die AHCI Version wird dir beim Booten angezeigt!
Ab 3.7.x.x.x sollte der Fehler behoben sein.
 
Zuletzt bearbeitet:
Ich lasse den Error Scan von HD Tune gerade noch zu Ende laufen. Knapp 3/4 durch, alles im grünen Bereich.
Hätte die Platte aber tats. einen SMART Error, müsste er ja nach dem Kaltstart auch angezeigt werden.
Von daher vermute ich, dass der Standard Windows AHCI-Treiber (msahci) hier was vercheckt
Ergänzung ()

Jo Berserkus, hatte ich vergessen zu erwähnen. Ist der Standard Windows AHCI-Treiber. Den AMD Treiber hab ich mir auch schon gedownloaded. Soll nach Google-Recherche evtl. helfen, den AMD Treiber via Geräte-Manager einzeln zu installieren. Da der msahci aber angeblich der Stabilste sein soll, wollte ich noch mal sehen, was ihr an meiner Stelle machen würdet, bevor der AMD Treiber eine Chance bekommt.

Neueste Firmware der SSD ist bereits drauf
 
Zuletzt bearbeitet:
julioo schrieb:
Von daher vermute ich, dass der Standard Windows AHCI-Treiber (msahci) hier was vercheckt
Das bestimmt nicht, bis zum Windowsstart ist es ja von dieser Stelle noch ein ganzes Stueck. Die Fehlermeldung kommt vom BIOS, welches nur den Status aber nicht die einzelnen Smart-Parameter abfragt. Also liefert die Platte entweder tatsaechlich einen Fehler auf die Abfrage von Smart zurueck oder das BIOS hat einen Bug. Bei letzterem sollte aber mit hoher Wahrscheinlichkeit auch die Abfrage der zweiten Platte zu einer Fehlermeldung fuehren.

Ich habe unter Windows z.B. immer CrystalDiskInfo laufen, welches den Smart-Status periodisch abfragt und gegebenenfalls einen Warnhinweis anzeigt. Der Drive Fitness Test von IBM/Hitachi funktioniert mWn auch auf Platten anderer Hersteller.
 
ja, am besten mal kurz mit Crystal Disk checken und wie @pprlepdc schreibt, kann es nicht am Treiber hängen da der Fehler schon im Bios angezeigt wird. Sollte die Platte keine Fehler aufweisen, würde ich einfach mal die Ports unter der Platten untereinander wechseln, um zu schauen, ob der Port betroffen ist (die SSD kannst du lassen wie sie ist).
 
Zuletzt bearbeitet:
Es liegt an der AHCI Firmeware!
Lies meinen ergänzten Post nochmal und führe die dortigen Tips aus!
 
Kann jmd. anhand der Smart-Werte (s. Bild oben) erkennen, ob mit der Platte alles in Ordnung ist?

@ pprlepdc:
Hast Recht, klingt jedenfalls nachvollziehbar...
Demnach würde also eine Install. des AMD AHCI-Treibers nichts bewirken, oder?
Also liefert die Platte entweder tatsaechlich einen Fehler auf die Abfrage von Smart zurueck oder das BIOS hat einen Bug.
Ersteres ist aber auch irgwie unwahrsch., denn hätte die Platte wirklich einen Schaden, der vom BIOS anhand eines Smart-Wertes erkannt wird, würde der error konsequenterweise auch nach einem Kaltstart angezeigt werden, meinste nicht?

@ Berserkus: ziehs mir jetzt rein....sekunde :)

@ nicoc: Gute Idee mit dem Port-Wechsel. Ich probiers mal nach dem Berserkus-Tip!
Ergänzung ()

Ok Berserkus, ich hab mir das mal angeschaut und hab nun Hoffnung, dass ein BIOS update die Lsg. ist. Habe momentan Version F7. Versteh ich dich richtig, dass die neueste Version F12B die neueste AHCI-Firmware nicht enthalten könnte, die uralte F6 hingegen schon? Klingt komplett unlogisch, werd nat. erst mal F12 testen... Momentan lass ich noch HD Tune zu Ende laufen und meld mich dann nach dem Bios Update noch mal.

PS: Aus dem von Berserker verlinkten Gigabyte Thread zitiert:
mal eine blöde Frage: Ist dein AHCI Treiber aktuell? AMD hatte da einige Treiber 8Ende letztes Jahr), die bei einem Reboot die Platte abgeschaltet haben. Dann kann es sein, dass SMART vielleicht einen Fehler meldet, weil die Platte noch nicht neu gestartet hat.
Wäre das dann wohl von Belang, welcher Treiber installiert ist?
 
Zuletzt bearbeitet:
julioo schrieb:
Demnach würde also eine Install. des AMD AHCI-Treibers nichts bewirken, oder?
Nein! Zumindest nichts bezueglich der Fehlermeldung.


Ersteres ist aber auch irgwie unwahrsch., denn hätte die Platte wirklich einen Schaden, der vom BIOS anhand eines Smart-Wertes erkannt wird, würde der error konsequenterweise auch nach einem Kaltstart angezeigt werden, meinste nicht? Kann jmd. anhand der Smart-Werte (s. Bild oben) erkennen, ob mit der Platte alles in Ordnung ist?
So die angezeigten Werte korrekt sind, sollte die Abfrage des Parameters "Airflow Temperatur" einen Fehler liefern. das wuerde auch erklaeren, warum nach einem Kaltstart keine Fehlermeldung kommt, nach einem Reboot jedoch schon.

Nachtrag zu Deinem Nachtrag: ;)
Wäre das dann wohl von Belang, welcher Treiber installiert ist?
Der installierte Treiber ist bei der Fehlermeldung vollkommen egal. Du koenntest auch Windows 1.0, (ein auf Deiner Hardware nicht lauffaehiges) AIX 3.1 oder einfach nur einen grossen Raw-Truecryptcontainer auf der Platte haben und wuerdest trotzdem diese Fehlermeldung bekommen.
 
Zuletzt bearbeitet:
mal eine blöde Frage: Ist dein AHCI Treiber aktuell? AMD hatte da einige Treiber 8Ende letztes Jahr), die bei einem Reboot die Platte abgeschaltet haben. Dann kann es sein, dass SMART vielleicht einen Fehler meldet, weil die Platte noch nicht neu gestartet hat.
Das ist de facto der Grund. Man sollte daher darauf achten, wenn möglich, daß das SATA-Controller-BIOS und dessen zugehöriger Treiber harmonieren, sprich aus der selben Reihe stammen.
Eine Kombination mit dem Windows-internen MSAHCI ist daher denkbar ungünstig und bringt Probleme, nicht immer - aber immer öfter. ;)
Es werden bei einem Warmstart / Reboot noch Befehle im Festplattencontroller ausgeführt die vom Treiber stammen, daher hier auch dieses Problem.
 
Sublogics schrieb:
Es werden bei einem Warmstart / Reboot noch Befehle im Festplattencontroller ausgeführt die vom Treiber stammen, daher hier auch dieses Problem.
Dann laeuft ja der Linuxtreiber nach einem Warmstart aus Windows heraus sozusagen virtualisiert auf dem Windowstreiber. Und wenn ich dann wieder einen OS-Wechsel zurueck und wieder hin und wieder zurueck mache, habe ich ja bald ein halbes Dutzend vertikal virtualiserter Treiber. Gruselige Vorstellung das. Gibt's zum Glueck aber nur im Geruechtekuechenbios. :rolleyes:
 
Öh, wollte pprlepdc antworten, dass die Treiber-Geschichte damit als Problem-Quelle gestrichen ist. Und nun laut Sublogics soll ich doch besser den AMD Treiber drauf packen? Also dann folg. schrittweise testen:
1. Bios Update
2. AMD AHCI Treiber install.
3. Port der Problem-Platte testweise nicht belegen und anderen nutzen

stimmts so?
 
@pprlepdc: Kleiner Polemiker?
Es handelt sich natürlich nur um das Abarbeiten von Befehlen wie das Schalten in den Stromsparmodus und vielleicht Leeren des Caches.
Daß da keine Treiber direkt mehr laufen sollte klar sein und auch dir klar sein daß ich das nicht meinte.
 
Nachtrag zum AMD Treiber (zitiert aus anderem Forum):
Credit to Sonyb! I have a Gigabyte GA-MA78GM-S2H. I did an installation of the AMD AHCI installer that I downloaded from AMD website. I verified that it was installed successfully (device manager) BUT I was still getting the S.M.A.R.T. error message. So I did what Sonyb suggested, which was to install the driver via device manager (update driver option) and it booted without any glitch. Thanks!
Beschreibt ja genau mein Problem, allerdings hört sich die Lsg. (normale Install. des AMD Treibers brachte nix, via Geräte Manager aber schon) nach unnachvollziehbarem Gefrickel an, werds aber wohl dennoch nachmachen...

Gentlemen, es ist Wochenende. Friede sei mit euch ;)
 
Zuletzt bearbeitet:
Sublogics schrieb:
Es handelt sich natürlich nur um das Abarbeiten von Befehlen wie das Schalten in den Stromsparmodus und vielleicht Leeren des Caches.
Alles Treiberspezifische ist mit dem Neustart weg. Wo sollte der Treiber auch herkommen? Im RAM steht er nicht mehr, in den Cache der CPU passt er nicht, und selbst wenn, kommt er nirgends mehr ran (vgl. Resetvektor, hwxface(acpi_reset), kbdctrl, triple_fault etc.). Sobald eine dieser Aktionen erfolgreich durchgefuehrt wurde, gibt es einfach keinen handlungsfaehigen Softwaretreiber mehr. :D
 
Zuletzt bearbeitet:
pprlepdc, vielleicht habe ich mich unklar ausgedrückt. Stelle dir folgenden Hergang vor um meinem Gedankengang folgen zu können:
Windows kriegt den Befehl des Neustartes. Als einer der letzten Aktionen gibt der Treiber der Festplatte den Befehl die letzten Schreibaktionen vom (Festplatten)-Cache auf die Platte zu schreiben und die Platte herunterzufahren (Plattenrotor aus, Kopf in sichere Position parken...). Letzteres sollte nur beim Herunterfahren und nicht beim Neustart geschehen, wird aber bei einigen Treibern offensichtlich nicht bedacht. Da das dauert ist das BIOS beim Reboot vielleicht schon beim POST und gibt in Folge dessen einen Fehler aus während die Platte(n) noch nicht wieder rechtzeitig angelaufen ist/sind, vllt. gar noch nichtmal den Befehl zum Abschalten vollständig abgearbeitet haben.
Ich kenne das selbst von einigen Treibern bei Intel-Controllern.
 
Sublogics schrieb:
Als einer der letzten Aktionen gibt der Treiber der Festplatte den Befehl die letzten Schreibaktionen vom (Festplatten)-Cache auf die Platte zu schreiben
Erst nachdem das geschehen und bestaetigt ist, gibt es den Befehl zum Reset. Alles andere waere Vabanque.


und die Platte herunterzufahren (Plattenrotor aus, Kopf in sichere Position parken...). Letzteres sollte nur beim Herunterfahren und nicht beim Neustart geschehen, wird aber bei einigen Treibern offensichtlich nicht bedacht.
Hab ich zwar noch nie gesehen, das waere entweder auf eine fehlerhafte Implementierung der Resetsequenz im Treibers oder, was ebenso wahrscheinlich ist, ein fehlerhaftes Plattenbios zurueckzufuehren. Ein fehlerhaftes Mainboardbios schafft das natuerlich auch, naemlich genau dann, wenn es auch bei einem Warmstart kurzzeitig den Befehl zum Runterfahren uebermittelt. Vorstellbar waere das als Notloesung, z.B. um ein fehlerhaftes Plattenbios, welches keinen ordentlichen reset-Status herstellen kann, zu umgehen.

Da das dauert ist das BIOS beim Reboot vielleicht schon beim POST und gibt in Folge dessen einen Fehler aus während die Platte(n) noch nicht wieder rechtzeitig angelaufen ist/sind, vllt. gar noch nichtmal den Befehl zum Abschalten vollständig abgearbeitet haben.
In diesem beschriebenen Fall bekommt das BIOS maximal einen Timeout, die Platte wird also gar nicht vom BIOS erkannt. Zu einem falschen Smart-Status wird das jedoch nicht fuehren. Kopf in Parkposition und Motor aus dauert uebrigens keine Sekunde und das Flashen der Caches muss ja erledigt werden, solange der Kernel noch laueft (s.o.).


Ich kenne das selbst von einigen Treibern bei Intel-Controllern.
Das kann ich kaum glauben, sind doch Intels storage-Treiber bisher (fast) ausnahmslos ziemlich gut gewesen. Ich wuerde da eher eines der obigen Probleme vermuten. Aber vermuten kann man viel und mit fehlerhaften Implementierungen an irgendeiner Stelle, kann man auch alle moeglichen wirklichen und auch nur scheinbaren Probleme "erzeugen" (Z.B. schicke man statt eines Reset die Platte in einen Selbsttest, dann ist sie nie fertig, bis das BIOS sie beim Hochfahren versucht abzufragen, ergo funktioniert sie (fast) nie ohne Kaltstart).
 
Zuletzt bearbeitet:
Daß es mit am Mainboard-BIOS liegt (wo ja meistens das SATA-Controller-BIOS integriert ist) halte ich ja auch für möglich, besser gesagt für ein Zusammenspiel aus Treiber und Controller-BIOS. Daß es aber definitiv auch am Treiber liegt kann ich z.B. am aktuellen Beta-Treiber für die Intel-RST reproduzieren. Nämlich dann wenn man die Beta 11.5.0.1149 an einem Controller mit einem ROM-BIOS aus der Reihe 11.0.x oder älter nutzt.
Bei einem Neustart hängt dann der POST eine halbe Ewigkeit, die Platten springen erst sehr verzögert wieder an, et cetera.
Von daher halte ich das auch beim Threadersteller für den Grund, zumindest mit einer ähnlichen Ursache.
Ich vermute daß der MSAHCI nicht mit dem aktuellen SATA-Controller-ROM seiner BIOS-Version klar kommt. Also wird es wohl helfen eines davon in einer anderen Version auszuprobieren.
 
Versteh ich dich richtig, dass die neueste Version F12B die neueste AHCI-Firmware nicht enthalten könnte, die uralte F6 hingegen schon? Klingt komplett unlogisch,

Klingt unlogisch, ist bei Gigabyte aber an der Tagesordnung.
Ob jetzt begründet, oder wegen Sauhaufen im Change-Management, bleibt dahingestellt.
Ich plädiere aus Erfahrung mit ähnlichen Spirenzchen der vergangenen Jahre für letzteres.
 
Update

Also die Lösung war denkbar einfach: Das BIOS Update auf die neueste Version 12 hats gebracht! Der HD tune Error Scan hatte zuvor die betreffende Platte als unbeschädigt analysiert. Dann das BIOS Update durchgeführt und nun läuft der Bootvorgang auch bei Reboots durch.
Die Auflistung der SATA Platten hab ich noch mal angehängt:
- Bei allen Platten wird nun "SMART Health" angezeigt. Ich hoffe, dass es als healthy interpretiert werden soll, oder?
- Unter Capability steht bei der SSD 1,5G und bei den HDDs 3G. Bin ich verpeilt oder warum hat die SSD nur die halbe Datenrate?
- Kurios: Das Problem sollte ja eig. ab der AHCI Firmware Version 3.7.x gelöst sein. Das BIOS Update enthält aber nur die Version 3.0.x, warums nun trotzdem läuft....?

Wäre froh, wenn Ihr noch kurz Eure Meinungen zu den 3 Punkten abgeben würdet.
 

Anhänge

  • IMAG0039.jpg
    IMAG0039.jpg
    274,2 KB · Aufrufe: 224
Zurück
Oben