SAS Controller erkennt manche WD Red nicht

  • Moin,

    ich bin mit meinem Latein am Ende, vielleicht hat einer von euch noch eine Idee.

    Ich habe letztens von Grindhavoc 4 3TB WD Reds gekauft. Am internen SATA Port meines Boards funktionieren alle vier, ein RAID Controller im IR und IT Mode (IBM M5015 und Dell PERC H310) erkennt nur zwei der vier Platten. Die Platten sind alle 100% identisch. Verkabelung habe ich mehrfach geprüft, mehrere Controller, mehrere Netzteile und Boards getestet. Auf Biegen und Brechen wollen die beiden Platten nicht an einem SAS HBA spielen, ihre identischen Geschwister allerdings schon. Interessant ist, dass die Platten auch gar nicht hochdrehen, sofern sie nicht an einen internen SATA Port eines Mainboards angeschlossen sind. Sowohl mit SAS auf SATA Kabel, wie auch nur mit einem Stromstecker drehen die Platten nicht hoch, Ich habe sowohl einen normalen SATA Stromanschluss, wie auch einen SATA auf Molex Adapter probiert.

    Hat irgendeiner von euch noch eine Idee, wonach ich noch schauen kann? Mich macht das allmählich wahnsinnig xD


    Vielen Dank & LG

    Lukas

  • Hast Du mal die Firmwareversionen der Platten verglichen? Nur weil sie baugleich sind, müssen sie noch lange nicht denselben Softwarestand haben.

    Ich werde mich von keinem einzzzigen Prozzzessor trennen.
    Jedoch lockt es mich beinahe, ihn Dir zu überlassen, nur um zu sehen, wie er Dich in den Wahnsinn treibt :evil:

    Meine Begehren

    1. Versuchen die Platten an den Datenkabeln zu rotieren um Fehler an den SAS Anschlüssen der Controller auszuschließen, sofern die nicht schon mittels anderer HDDs verifiziert wurden.
    2. 4 andere SATA Platten an den RAID Controllern testen um zu sehen, ob das normal geht.
    3. Erst Mal auf die Controllerfirmware pfeifen und in ein Betriebssystem booten; Dort die Platten mittels Managementsoftware der Controller suchen und schauen ob da was zu erkennen ist. Vielleicht meldet ein RAID Controller aufschlußreiche Fehler an den betroffenen Ports?
    4. Platten an SATA wegnullen (Mit Nullen überschreiben, z.B. mit dd unter Linux) und dann nochmal an SAS testen, nur um ganz sicher zu sein, daß die Dinger da nicht irgendwas "komisches" als fehlerhafte RAID Metadaten interpretieren.

    Aller Wahrscheinlichkeit nach wird nichts davon zum Ziel führen, ich sag's gleich. Ich halte die von mir genannten Tips für ziemlich sicher nutzlos.

    Ich weiß nur nicht was man da sonst noch vorschlagen sollte. Vor allem nicht wenn du schon mehrere Netzteile, Boards und Controller durch hast. Das ist schon eine etwas härtere Ausgangslage. Man kann nicht Mal die Disks beschuldigen wenn alle die selbe FW haben und an SATA normal laufen...

    1-6000-banner-88x31-jpg

    Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:

    • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700

    [//wp.xin.at] - No RISC, no fun!

    QotY: Girls Love, BEST Love; 2018 - Lo and behold, for it is the third Coming; The third great Year of Yuri, citric as it may be! Edit: 2019 wasn't too bad either... Edit: 2020... holy crap, we're on a roll here~♡!

    Quote Bier.jpg@IRC 2020: "Je schlimmer der Fetisch, desto besser!"

    1. Versuchen die Platten an den Datenkabeln zu rotieren um Fehler an den SAS Anschlüssen der Controller auszuschließen, sofern die nicht schon mittels anderer HDDs verifiziert wurden.

    Rotation von diversen Platten, Ports und Datenkabeln hab ich bereits durch, das hilft nicht.

    4 andere SATA Platten an den RAID Controllern testen um zu sehen, ob das normal geht.

    dito

    Erst Mal auf die Controllerfirmware pfeifen und in ein Betriebssystem booten; Dort die Platten mittels Managementsoftware der Controller suchen und schauen ob da was zu erkennen ist. Vielleicht meldet ein RAID Controller aufschlußreiche Fehler an den betroffenen Ports?

    In Windows, bzw dem MegaRAID Storage Manager wird nichts angezeigt, unabhängig von Controllerversion, aber ich hab noch was gefunden, siehe unten.

    Platten an SATA wegnullen (Mit Nullen überschreiben, z.B. mit dd unter Linux) und dann nochmal an SAS testen, nur um ganz sicher zu sein, daß die Dinger da nicht irgendwas "komisches" als fehlerhafte RAID Metadaten interpretieren.

    Ich wüsste nicht, was das bringen soll, die Platte dreht ja nichtmal, wenn ein Kabel zum SAS Controller eingesteckt ist. Ich befürchte, dass der SATA und SAS Controller die Platten irgendwie leicht anders initialisieren, und das aus irgendwelchen Gründen zwei der Platten Sauer aufstößt.

    Was ich noch festgestellt habe:

    Ich habe hier einen Uralten LSI 1064i SAS Controller liegen. Der kommt mit den Platten nciht klar, weil er maximal 2TB abkann, aber aus Spaß hab ich da mal eine rangehängt: Die funktionierenden Platten werden erkannt, mit 2047GB. Mit einer der merkwürdigen Platten erhalte ich allerdings vom Controllerbios dann einen "SAS DISCOVERY ERROR 0x000000002 on adapter 0, port 1". Das ist merkwürdig. Hier scannt die Kiste dann minutenlang rum, und bootet nicht weiter. Ich werde jetzt mal testen, was passiert, wenn ich mit diesem Controller hotplugge, und dann schaue, was der MegaRaid Storage Manager sagt.

    EDIT: Der MSM schmeißt beim Hotpluggen an diesem Controller einen Error "SAS topology error: device not addressable"

  • Ich wüsste auch nicht (wenig bis gar nicht) was es bringen soll. Aber du hast hier schon ein seltenes Einhorn der Diskfehler gefunden, da isses schwierig...

    Das hilft dir jetzt auch nichts weiter, aber: Im SAS Fall werden die Platten per STP (SATA Tunneling Protocol) durch SAS durchgereicht. D.h. ja, die Initialisierung ist anders als an regulärem SATA, zumindest für den Controller, wenn schon nicht für die Disk.

    Aber das erklärt mir noch nicht, wieso sich zwei von vier ansonsten völlig identischen Platten hier anders verhalten. Staggered Spin-Up z.B. greift auf Portebene, hier werden also z.B. zuerst Ports 0 und 1 hochgenommen und danach Ports 2 und 3. Wenn wir annehmen, daß der Fehler im verzögerten Hochdrehen läge, dann sollten aber immer z.B. Ports 2 und 3 betroffen sein und nicht immer die exakt gleichen beiden HDDs.

    Ich frage mich grade, ob es bei WD eventuell Unterschiede in der Firmware bei augenscheinlich gleicher Version geben könnte. Also wenn nicht der Nutzer die Firmware aktualisiert hätte, sondern die ab Werk geflashte genutzt wird.

    Vielleicht könnte man ja noch versuchen alle Disks auf die jeweils neueste FW zu flashen, auch wenn alle so aussehen als ob's die gleiche hätten? Das sind Strohhalme, wie gesagt. Aber wenn wir davon ausgehen wollen, daß die Fehler an spezifischen Platten liegen...

    1-6000-banner-88x31-jpg

    Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:

    • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700

    [//wp.xin.at] - No RISC, no fun!

    QotY: Girls Love, BEST Love; 2018 - Lo and behold, for it is the third Coming; The third great Year of Yuri, citric as it may be! Edit: 2019 wasn't too bad either... Edit: 2020... holy crap, we're on a roll here~♡!

    Quote Bier.jpg@IRC 2020: "Je schlimmer der Fetisch, desto besser!"

  • Die Fehler sind definitiv spezifische Platten. Staggered Spinup oder so Spielereien habe ich gar nicht aktiv. Im Moment ist mein Testsystem ein Dell PERC H310 auf IT Mode geflasht, ein 2600K auf einem P8P67 Deluxe und 32GB RAM. Dann habe ich da jeweils eine funktionierende und eine nicht funktionierende der Reds liegen. Grindhavoc meinte, er hätte die Platten zuletzt am einer Areca Raidkarte betrieben, wo sie einwandfrei liefen.

    Firmware-Update ... Den Gedanken hatte ich auch schon, aber ich war nicht in der Lage, etwas zu finden. Vielleicht kontaktiere ich da Mal den WD Support, mit ein bisschen Glück rücken die was raus, auch wenn die Platten schon etwas älter sind.

    Betreffend SATA over SAS: ich dachte mir fast schon, dass das Problem in der Art der Initialisierung liegt, da sie _nur_ an einem SATA Kabel, was mit dem Mainboard verbunden ist, hochdrehen. Wenn ich die 'defekte' Red aber hotplugge, höre ich die Drehzahl der anderen Platten kurz einbrechen, soviel Strom sollte eine gesunde Platte imo nicht ziehen. Das werde ich vielleicht morgen auch Mal messen, wenn der WD Support nichts sagt.

    Ich tendiere fast dazu, die EEPROMs einer gesunden und kranken Platte Mal auszulesen und zu vergleichen, ob die abgesehen von den spezifischen Daten der Plattengeometrie her identisch sind.

  • hallöchen,

    ja genau, ich hatte 16x WD Red 3TB an einem Areca 1280ML (RAID6) am laufen.

    Ich konnte keine Probleme oder Unterschiede feststellen.

    Wie sind denn die Herstellungsdaten der HDDs? Sind die evtl. beide älter oder neuer, als die anderen?

    Hat WD da evtl. ein Feature verändert?

    WDIDLE / WDTLER Werte mal verglichen (wobei ich gerade nicht weiß ob die 3TBs das noch unterstützen)?

  • Die sind alle ziemlich identisch, habe ich geprüft. WDIDLE und WDTLER nich nicht. Der WD Support hat sich noch nicht gemeldet, aber ich habe parallel den Thread auch nochmal im Luxx eröffnet, vielleicht fällt den schlauen Leuten da noch was ein ^^

  • Ich habe das Problem gefunden!

    Mir hat es keine Ruhe gelassen, und der Durst nach mehr Storage hat mich die zwei RED im Schrank wieder finden lassen. Ich habe einiges an Troubleshooting betrieben, und sogar eine ähnliche Platte bei ebay geschossen, und EEPROM Inhalte verglichen, ROMs getauscht, und Bits gedreht - alles erfolglos.

    Mit ein klein wenig Hilfe aus dem hddguru-Forum habe ich das Problem identifiziert: die zwei Platten booten in den PUIS-Modus. PUIS steht für Power Up in Standby. Der SATA Controller weckt die Platten also aus diesem aus, mein SAS Controller und mein USB Gehäuse nicht. Als das Problem identifiziert war, konnte ich die Platten einfach in einen Rechner hängen, der sie am SATA Port erkennt, und mittels des Tools hdat2 den PUIS Modus deaktivieren. Schon verhalten sich die Dinger, wie sie sollen. Wenn man den Fehler gefunden hat, ist es ganz simpel :)

  • Oha, durchaus interessant, ist mir noch nicht begegnet. Gut zu wissen!

    1-6000-banner-88x31-jpg

    Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:

    • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700

    [//wp.xin.at] - No RISC, no fun!

    QotY: Girls Love, BEST Love; 2018 - Lo and behold, for it is the third Coming; The third great Year of Yuri, citric as it may be! Edit: 2019 wasn't too bad either... Edit: 2020... holy crap, we're on a roll here~♡!

    Quote Bier.jpg@IRC 2020: "Je schlimmer der Fetisch, desto besser!"