XP Festplatten schalten bei Neustart aus
- Ersteller Dalai
- Erstellt am
Dalai
Grand Admiral Special
Hallo Leute,
um folgende Hardware geht's:
Folgendes Problem: die Platten werden bei jedem Neustart des OS ausgeschaltet, 1 Sekunde später (wenn sie noch nicht komplett angehalten haben) wieder eingeschaltet, um unmittelbar danach erneut ausgeschaltet zu werden. Das passiert ausschließlich mit XP64, aber nicht mit XP32 (anderer Treiber für x86 mit derselben Treiberversion).
Selbes Spiel übrigens mit einer der neueren Treiberversionen 1.5.12073 oder 1.6.12082.
Wo kann das Problem liegen? Treiber oder OS? Ans OS glaub ich fast nicht, weil das XP64 auf meinem Rechner keinen solchen Schmonz macht, auch wenn das natürlich komplett andere Hardware ist.
MfG Dalai
um folgende Hardware geht's:
- Board: GA-MA785G-UD3H mit BIOS F4
- CPU: Athlon II X2 240
- Controller: Adaptec 1220SA mit BIOS 2328 und Treiber 1.4.12047 (WHQL)
- Platten: 2x WD5002ABYS RE3, Firmware 3B03, im RAID-1
- OS: XP x64 OEM mit integriertem SP2
Folgendes Problem: die Platten werden bei jedem Neustart des OS ausgeschaltet, 1 Sekunde später (wenn sie noch nicht komplett angehalten haben) wieder eingeschaltet, um unmittelbar danach erneut ausgeschaltet zu werden. Das passiert ausschließlich mit XP64, aber nicht mit XP32 (anderer Treiber für x86 mit derselben Treiberversion).
Selbes Spiel übrigens mit einer der neueren Treiberversionen 1.5.12073 oder 1.6.12082.
Wo kann das Problem liegen? Treiber oder OS? Ans OS glaub ich fast nicht, weil das XP64 auf meinem Rechner keinen solchen Schmonz macht, auch wenn das natürlich komplett andere Hardware ist.
MfG Dalai
Zuletzt bearbeitet:
Dalai
Grand Admiral Special
Hat irgendjemand ein solches oder ähnliches Problem schonmal gehabt? Kommt schon, ich weiß, dass es wissende Leute in diesem Forum gibt 
. Habt Mitleid mit den Platten, denn denen tut das auf Dauer nicht gut 
.
MfG Dalai
. Habt Mitleid mit den Platten, denn denen tut das auf Dauer nicht gut .MfG Dalai
- Mitglied seit
- 25.05.2002
- Beiträge
- 29.374
- Renomée
- 1.573
http://www.hardwareluxx.de/community/showthread.php?t=243048Hat irgendjemand ein solches oder ähnliches Problem schonmal gehabt? Kommt schon, ich weiß, dass es wissende Leute in diesem Forum gibt
MfG Dalai
Dalai
Grand Admiral Special
Dankeschön für den Hinweis. Damit ist wohl klar, dass es am Treiber liegt, der aber schon so alt ist, dass nicht mehr mit einem Update zu rechnen sein dürfte
... Und den Intel-Treiber kann ich leider auch nicht nehmen 
.Das sieht für mich nach einem Controllerwechsel aus - dabei wurde der erst vergangene Woche gekauft
![:]](https://www.planet3dnow.de/vbulletin/images/smilies/rolleyes.gif "Augen rollen (sarkastisch) :]")
, aber wer geht schon von einem solchen Unsinn aus? Hat jemand Erfahrungen diesbzgl. mit einem Dawicontrol DC300e oder einem anderen Controller mit Silicon Image 3132? Lustigerweise hat ja der Adaptec ebenfalls diesen Chip, aber die Device ID ist ne andere, sodass der SiL-Treiber sich nicht verwenden lässt 
...Bevor aber endgültig ein anderer Controller gekauft wird, werde ich Adaptec noch auf den Sack gehen. Irgendwie kann ich mir nicht vorstellen, dass die nichts davon wissen.
MfG Dalai
Denniss
Grand Admiral Special
Da kann man aber in der INF-Datei des Treibers die passende ID vom Adaptec hinzufügen und es sollte klappen.
Habe das mal bei einer D-Link WLAN-Karte gemacht, da war zwar ein Realtek-Chipsatz drauf aber mit von D-Link verbogener ID. Die passende ID in die Inf-Datei und wird sauber erkannt und läuft.
Dalai
Grand Admiral Special
Ich glaube nicht daran, dass das funktioniert, davon abgesehen, dass dabei die Signatur flöten geht. Ich werd's dennoch mal probieren, es existiert immerhin ein Image
. Momentan gibt's noch andere Probleme, weil nicht nur Adaptec unfähig ist . Weil's grad so schön zum Thema passt: der hier bemängelte Treiber verursacht ~20% CPU-Last bei einem Verify des RAID! Unter Win2k waren es 4%.MfG Dalai
Woodstock
Grand Admiral Special
Ich setz bei mir den DC300e und den DC310e ein. Den DC300e unter XP 32 Bit und den DC310e und Vista 64.
Ich kann bei keinen System ein an und abschalten der Platten beim Booten feststellen.
Aber warum nimmst du XP 64? Es ist doch bekannt das es bei XP 64 mit den Treibern nicht so gut bestellt ist.
Bei einem Bekannten habe ich einen 08/15 Controller mit Sil3132 verbaut. XP 32 und auch dort keine Auffälligkeiten
Zuletzt bearbeitet:
Dalai
Grand Admiral Special
Weil die Lizenz vorhanden ist (sogar 2) und Fakt ist: es gibt einen Treiber, nur funktioniert der saumäßig. D.h. die Grundfunktionen tun, nur eben das Abschalten der Platten beim Neustart und die hohe Last beim Verify, die mir vorhin erst auffiel, sind NoGos.
Bei XP32 gibt's ja auch keine Probleme. Nur: ich will nicht nur wegen diesem Scheiß auf XP32 gehen. Die anderen Probleme, die momentan noch bestehen, gäbe es auch mit XP32, und das nur, weil ein Softwarehersteller meint, seine Softwarelizenzen für Multiprozessorsysteme anders zu handhaben
.... und das im Jahr 2010.MfG Dalai
Woodstock
Grand Admiral Special
Ich setz den Dawicontrol aber auch unter Vista 64 ein und habe da keine Probleme.
In wieweit das auf XP64 auch zutrifft vermag ich nicht zu sagen.
Wenn du unbedingt XP 64 nehmen willst wirst du wohl mit dem Treiber Problem leben müßen. Das hier noch mal ein neuer Treiber kommt glaub ich nicht. XP ist tot
Bleibt nur die INF zu ändern oder einen anderen Controller kaufen
Ich nehme nicht an das de Adaptec Vista Treiber in der Version 1.6.12088 von September 2008 mit XP läuft.
In wieweit das auf XP64 auch zutrifft vermag ich nicht zu sagen.
Wenn du unbedingt XP 64 nehmen willst wirst du wohl mit dem Treiber Problem leben müßen. Das hier noch mal ein neuer Treiber kommt glaub ich nicht. XP ist tot
Bleibt nur die INF zu ändern oder einen anderen Controller kaufen
Ich nehme nicht an das de Adaptec Vista Treiber in der Version 1.6.12088 von September 2008 mit XP läuft.
Dalai
Grand Admiral Special
So, INF wurde angepasst, aber wie zu erwarten: BSOD mit STOP 07B. Lag wohl auch daran, dass er kein Pseudo Processor Device installieren konnte, denn beide Controller (Adaptec und Sil3132) brauchen 2 Geräte: Controller selbst und ein Pseudo Device.
Ergänzung: Treiber 1.6.12088 lässt sich nicht installieren, weil Windows meint, dass der angegebene Ort keine Informationen über die Hardware enthält - das ist demzufolge ein reiner Vista/2k8-Treiber.
MfG Dalai
Ist es nicht, schon gar nicht in Firmen. Und besagter Rechner wird ein Server in einer solchen.Woodstock schrieb:
Das hab ich bisher nicht probiert, weil Adaptec angibt, dass dafür ein neueres BIOS nötig ist (2330) und ich mir nicht vorstellen kann, dass dieses "Feature" (für mich ist es ein Bug) dort nicht mehr enthalten ist. Aber ich werde es dennoch probieren, wobei das Wechseln des Controllers irgendwie die bessere Lösung ist...Woodstock schrieb:
Ergänzung: Treiber 1.6.12088 lässt sich nicht installieren, weil Windows meint, dass der angegebene Ort keine Informationen über die Hardware enthält - das ist demzufolge ein reiner Vista/2k8-Treiber.
MfG Dalai
Zuletzt bearbeitet:
Woodstock
Grand Admiral Special
Was für ein Pseudo Processor Device?
Meinen Dawicontrol finde ich im Gerätemanager von Vista unter Speichercontroller als:
Silicon Image Sil 3132 SATALink Controller
Was anders finde ich nicht das ich dem Controller zuordnen könnte.
Doch. XP ist tot. Zumindest was die Treiberentwicklung vieler Hersteller angeht. Ich habe ja nicht gesagt das es beim Anwender oder in Firmen tot ist.
Wenn das Ding schon als Server missbraucht wird würde ich kein XP 64 nehmen.
Schon gar nicht wenn die Treiber nicht richtig funktionieren
Das habe ich befürchtet das es nicht klappt. Einen Versuch wars aber wert.
Dann wirst Du wohl oder übel auf XP 32 zurückgreifen müßen oder Du suchst dir einen anderen Controller.
Wie gesagt kann ich nicht sagen ob die Dawicontroll auch diese Problem unter XP64 haben. Unter Vista 64 habe ich keine Probleme.
Bei den Dawicontrollern hast du aber die Möglichkeit Treiber direkt von www.Siliconimage.com zu holen.
Schattenreich
Grand Admiral Special
jo kann ich bestätigen liegt am AHCI
win7 64 bit und mit vista 32 bit
im AHCI modus die selben probleme
win7 64 bit und mit vista 32 bit
im AHCI modus die selben probleme
Dalai
Grand Admiral Special
Schau mal in die INF des Treibers (beim Sil ist es sippd.inf, beim Adaptec steht's in den älteren Versionen mit in der adp3132.inf). Kann durchaus sein, dass Vista kein solches Gerät mehr braucht oder es versteckt ist
.Mag sein. Nur warum sollte ich Vista oder Win7 nehmen, wenn eine XP64-Lizenz vorhanden ist und demzufolge jede Änderung des OS Geld kosten würde (ein Server OS nicht unter 400€)?
Sondern?
Richtig, deswegen fliegt der Controller raus, wenn Adaptec keine Lösung hat. Ist die billigste Lösung, zumal bisher alle nötigen Programme laufen.
Genau deswegen bin ich auch bei denen hängengeblieben.
MfG Dalai
Dalai
Grand Admiral Special
Kleines Update:
MfG Dalai
- Das Problem tritt nicht mit XP64 SP1 auf. Sobald man SP2 nachinstalliert, schalten die Platten wieder ab beim Neustart des Systems. Fazit: mindestens auf besagter Hardware im Zusammenspiel des Adaptec-Treibers mit XP64 SP2 gibt's das Problem.
- Adaptec weiß natürlich von nichts. Vermutung: zu wenige Leute setzen diesen Controller mit XP64 SP2 ein, ein gewisser Prozentsatz davon wird das Problem nicht bemerken und wieder andere werden es nicht als solches wahrnehmen bzw. es wird sie nicht stören.
- Parallel zur Ursachenforschung wurde ein DC-300e bestellt, wir lassen uns überraschen, ob das Problem dort ebenfalls existiert - Dawicontrol hat es zwar verneint, aber ich nehme mir die Freiheit, die zur Sau zu machen, wenn das Gegenteil der Fall sein sollte .
MfG Dalai
PuckPoltergeist
Grand Admiral Special
Wenn es mit SP2 erst auftritt, evtl. doch mehr Windows-spezifisch? Um mal ganz böse zu sein, hast du schon mit Linux getestet?Kleines Update:
- Das Problem tritt nicht mit XP64 SP1 auf. Sobald man SP2 nachinstalliert, schalten die Platten wieder ab beim Neustart des Systems. Fazit: mindestens auf besagter Hardware im Zusammenspiel des Adaptec-Treibers mit XP64 SP2 gibt's das Problem.
- Adaptec weiß natürlich von nichts. Vermutung: zu wenige Leute setzen diesen Controller mit XP64 SP2 ein, ein gewisser Prozentsatz davon wird das Problem nicht bemerken und wieder andere werden es nicht als solches wahrnehmen bzw. es wird sie nicht stören.
- Parallel zur Ursachenforschung wurde ein DC-300e bestellt, wir lassen uns überraschen, ob das Problem dort ebenfalls existiert - Dawicontrol hat es zwar verneint, aber ich nehme mir die Freiheit, die zur Sau zu machen, wenn das Gegenteil der Fall sein sollte
MfG Dalai
Dalai
Grand Admiral Special
Ja und nein. Win2k SP4 ist kein Problem, XP SP3 auch nicht, nur XP64 SP2. Meine Vermutung ist ja, dass es mit anderen Controllern nicht auftritt, weil die andere Treiber haben. Im von cruger verlinkten Thread ist das auch ersichtlich: die neueren Intel-Treiber machen Probleme, die älteren nicht.
System Rescue CD (Version 1.3.x) habe ich natürlich ausprobiert, überhaupt kein Problem.
Nur: auf diesem Server wird leider wirklich Windows gebraucht. Der Rechner ist neben den beiden Linux-Server der einzige Windows-Server, der eben die Aufgaben übernimmt, für die es keine Linux-Lösungen gibt. Momentan ist das eine Verteillösung für's Antivirenprogramm, eine Lösung zum Auslesen der Telefonanlage, c't Offline Update (OK, inzwischen gibt's dafür Linux-Skripte), PDF-Mailer (dafür schauen wir uns noch nach einer freien Lösung um) und weitere Kleinigkeiten.
MfG Dalai
PuckPoltergeist
Grand Admiral Special
Mir ging es nur ums Gegenchecken bzgl. OS-Abhängigkeit. Weiß ja selber, dass für bestimmte Aufgaben bestimmte Systeme einfacher oder einfach nur notwendig sind.
Bin selber kein Freund von Adaptec (zu böse Negativ-Erfahrungen), aber hier müssen sie nicht Schuld sein. Irgend etwas macht das OS da auch noch im Hintergrund. Hast du sie schon mal auf deine Testergebnisse hingewiesen?
Dalai
Grand Admiral Special
Klar
. Bei solchen Sachen teste ich das immer zuerst mit anderen OS. Aber da ich mit Win2k angefangen, mit XP32 weitergemacht und dann bei XP64 in diese Probleme gelaufen bin, konnten die nur noch am OS oder Treiber liegen.Je nachdem, wie diese Sache hier ausgeht, tendiere ich auch dorthin...
Momentan sieht es allerdings so aus. Wir werden sehen. Morgen dürfte der DC-300e eintreffen, dann werden wir's wissen.
Einer vom Adaptec-Support hat mit folgender Hard-/Software getestet und kein Problem feststellen können:
- 2x 400GB Hitachi
- Adaptec 1220SA mit BIOS 2227 und Treiber 1.6.12082
- XP64 SP1
MfG Dalai
PuckPoltergeist
Grand Admiral Special
Denke mal, gerade deine Erfahrungen mit SP1/SP2 dürfte für die interessant sein. Bin mal gespannt auf deren Reaktion.
Dalai
Grand Admiral Special
Es gibt Neues:
- Adaptec hat sich bisher noch nicht wieder gemeldet , ich glaub ich muss die nochmal anrufen - hab ja auch nix besseres zu tun *nerv*.
- Der DC-300e ist heute endlich eingetroffen. Und wie ich schon erwartet hatte, macht der keine derartigen Probleme. Derzeit gibt's zwar noch ein anderes Problem (Kiste hängt nach chkdsk beim Booten), aber mal schauen, ob sich das noch lösen lässt.
Dalai
Grand Admiral Special
Update:
Problem mit Hängenbleiben nach chkdsk ist gelöst. Das war nur das Sichtbare eines tieferen Problems, das sich zusätzlich ganz hässlich darstellt. Einträge in der Ereignisanzeige mit diesem Inhalt:
Interessant dabei: die passen zeitlich genau zum Prüfzeitpunkt, wonach er dann hängenbleibt 
.
Mein allererster Gedanke beim wiederholten Hängenbleiben beim chkdsk: ach du Scheiße, nicht noch ein Reinfall mit einem Controller... Dann hab ich die oben erwähnten Einträge im Eventlog gesehen und mir gedacht: Treiber oder Kabel. Platten kamen zwar im Prinzip auch als Ursache in Frage, aber da die bislang ohne Probleme liefen, sah ich die Wahrscheinlichkeit dort als sehr gering; davon abgesehen ist es ja ein RAID-1.
Also hab ich Kabel umgesteckt, Treiber getauscht, OS hin- und herinstalliert. Nach einem kompletten Arbeitstag komme ich zu diesem Ergebnis
Fazit: Adaptec ist also nicht allein beim Verpatzen von Treibern, Silicon Image kann das auch. In diesem Fall ist das sogar noch schlimmer, denn erstens sind hier sowohl die x64 als auch die x86 Treiber betroffen (ja, ich hab auch XP32 getestet) und zweitens führt das zu Datenkorruption, was für einen Treiber ein absolutes NoGo ist!
Ich bleib bei Version 1.5.5, weil das die letzte ist, die offiziell nicht für Vista gedacht ist (wer weiß, was Sil da sonst noch umgebaut hat, was auf lange Sicht zu Problemen führt) und weil die Funktionalität des "Sicheren Entfernens" der Platten an der Stelle nun wirklich nicht gebraucht wird - die neueren Treiber ab 1.5.10 können das.
So long, in der Hoffnung, dass man nun endlich mal zum eigentlichen Problem kommen kann: den gestorbenen Rechner ersetzen.
MfG Dalai
Problem mit Hängenbleiben nach chkdsk ist gelöst. Das war nur das Sichtbare eines tieferen Problems, das sich zusätzlich ganz hässlich darstellt. Einträge in der Ereignisanzeige mit diesem Inhalt:
Code:
the file system structure on the disk is corrupt and unusable. please run chkdsk an the volume \bla\blubMein allererster Gedanke beim wiederholten Hängenbleiben beim chkdsk: ach du Scheiße, nicht noch ein Reinfall mit einem Controller... Dann hab ich die oben erwähnten Einträge im Eventlog gesehen und mir gedacht: Treiber oder Kabel. Platten kamen zwar im Prinzip auch als Ursache in Frage, aber da die bislang ohne Probleme liefen, sah ich die Wahrscheinlichkeit dort als sehr gering; davon abgesehen ist es ja ein RAID-1.
Also hab ich Kabel umgesteckt, Treiber getauscht, OS hin- und herinstalliert. Nach einem kompletten Arbeitstag komme ich zu diesem Ergebnis
- der neuste Treiber 1.5.18.0 ist schuld, alle verherigen Versionen 1.5.5, 1.5.10 und 1.5.14.1 laufen ohne diese Probleme - verursachen also keine Einträge im Eventlog und der Rechner startet sofort nach chkdsk neu. Interessant ist, dass die 1.5.14.1 unsigniert ist, obwohl eine *.cat beiliegt.
Fazit: Adaptec ist also nicht allein beim Verpatzen von Treibern, Silicon Image kann das auch
. In diesem Fall ist das sogar noch schlimmer, denn erstens sind hier sowohl die x64 als auch die x86 Treiber betroffen (ja, ich hab auch XP32 getestet) und zweitens führt das zu Datenkorruption, was für einen Treiber ein absolutes NoGo ist!Ich bleib bei Version 1.5.5, weil das die letzte ist, die offiziell nicht für Vista gedacht ist (wer weiß, was Sil da sonst noch umgebaut hat, was auf lange Sicht zu Problemen führt) und weil die Funktionalität des "Sicheren Entfernens" der Platten an der Stelle nun wirklich nicht gebraucht wird
- die neueren Treiber ab 1.5.10 können das.So long, in der Hoffnung, dass man nun endlich mal zum eigentlichen Problem kommen kann: den gestorbenen Rechner ersetzen
.MfG Dalai
Dalai
Grand Admiral Special
Nachdem ich Adaptec nochmals telefonisch genervt habe, haben sie es dann auch mal mit SP2 versucht. Doch auch nach dessen Installation, sowie anschließender Installation aller verfügbarer Patches und des IE8 haben sie kein Problem feststellen können.
Der Adaptec-Techniker vermutet einen Zusammenhang mit dem Chipsatz-Treiber - ich gehe da eher in Richtung Festplatten in Zusammenspiel mit diesem Controller und dessen Treiber. Denn welcher Chipsatz-Treiber soll nach dem Abschluss des Textmode-Setups geladen sein? Die Platten schalten ja schon zu diesem Zeitpunkt (erster Reboot im Windows-Setup) ab.
Kapitel Adaptec ist damit für diesen Controller abgeschlossen. Schade, denn deren Monitoring-Software und auch das Controller-BIOS ist besser als das, was Dawicontrol oder Silicon Image für diesen Chip bieten...
MfG Dalai
Der Adaptec-Techniker vermutet einen Zusammenhang mit dem Chipsatz-Treiber - ich gehe da eher in Richtung Festplatten in Zusammenspiel mit diesem Controller und dessen Treiber. Denn welcher Chipsatz-Treiber soll nach dem Abschluss des Textmode-Setups geladen sein? Die Platten schalten ja schon zu diesem Zeitpunkt (erster Reboot im Windows-Setup) ab.
Kapitel Adaptec ist damit für diesen Controller abgeschlossen. Schade, denn deren Monitoring-Software und auch das Controller-BIOS ist besser als das, was Dawicontrol oder Silicon Image für diesen Chip bieten...
MfG Dalai
