TS-879U-RP findet 2x REXP1620 nicht mehr

  • Die Lieferzeiten sind momentan leider bescheiden, ich warte auch noch auf zwei TS-831XU.
    Bitte auf dem Laufenden halten!

  • - Neuer Server ist eingetroffen (Firmware: v.4.2.2)
    - Firmware mit Qfinder Pro Manuell auf v. 4.2.5 aktualisiert
    - Alter & Neuer Server heruntergefahren
    - PCIe SAS Controller + SFP LWL Karte getauscht
    - Neuen Server gestartet: findet keine REXP
    - DMESG Ausgabe (gleicher Fehler wie vorher)


    Code
    [    6.538529] mpt3sas0: 64 BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem (8136304 kB)[    6.538541] mpt3sas0: fault_state(0x26b5)![    6.538542] mpt3sas0: sending diag reset !!...snip...[    7.437921] mpt3sas0: diag reset: SUCCESS[    7.519883] mpt3sas0: IOC Number : 0[    7.519932] mpt3sas 0000:01:00.0: irq 56 for MSI/MSI-X[    7.519937] mpt3sas 0000:01:00.0: irq 57 for MSI/MSI-X[    7.519941] mpt3sas 0000:01:00.0: irq 58 for MSI/MSI-X[    7.519947] mpt3sas 0000:01:00.0: irq 59 for MSI/MSI-X[    7.519985] mpt3sas0-msix0: PCI-MSI-X enabled: IRQ 56[    7.519986] mpt3sas0-msix1: PCI-MSI-X enabled: IRQ 57[    7.519986] mpt3sas0-msix2: PCI-MSI-X enabled: IRQ 58[    7.519987] mpt3sas0-msix3: PCI-MSI-X enabled: IRQ 59[    7.519988] mpt3sas0: iomem(0x00000000b3040000), mapped(0xffffc90010200000), size(65536)[    7.519989] mpt3sas0: ioport(0x0000000000006000), size(256)[    7.595854] mpt3sas0: IOC Number : 0[    7.631852] 64bit 0000:01:00.0 uses identity mapping[    7.658980] mpt3sas0: Allocated physical memory: size(16059 kB)[    7.658981] mpt3sas0: Current Controller Queue Depth(8467), Max Controller Queue Depth(8704)[    7.658982] mpt3sas0: Scatter Gather Elements per IO(128)[    7.718255] mpt3sas0: LSISAS3008: FWVersion(12.00.00.00), ChipRevision(0x02), BiosVersion(08.15.00.00)[    7.718256] mpt3sas0: Protocol=(Initiator,Target), Capabilities=(TLR,EEDP,Snapshot Buffer,Diag Trace Buffer,Task Set Full,NCQ)[    7.718289] mpt3sas0: : host protection capabilities enabled  DIF1 DIF2 DIF3[    7.718291] mpt3sas0: sending port enable !!...snip....[   24.467733] mpt3sas0: _config_request: timeout[   24.467735] mf:[   24.467735]     04000000 00100000 00000000 00000000 00000000 0f000005 00000000 d3000000[   24.467735]     ffffffff ffffffff 00000000[   24.467741] mpt3sas0: fault_state(0x26b5)![   24.467742] mpt3sas0: sending diag reset !![   25.367429] mpt3sas0: diag reset: SUCCESS[   25.367620] mpt3sas0: failure at /root/daily_build/4.2.2/NasDriver/drivers/mpt3sas-8.00.00.00/mpt3sas_scsih.c:5948/_scsih_sas_host_add()![   25.377415] mpt3sas0: port enable: FAILED with (ioc_status=0x00000004)....snip....[  210.600356] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=1)[  211.600994] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=2)[  212.601633] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=3)[  213.602279] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=4)[  214.602908] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=5)[  215.603547] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=6)[  216.604183] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=7)[  217.604829] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=8)[  218.605432] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=9)[  219.606096] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=10)[  219.606098] mpt3sas0: _ctl_do_mpt_command: failed due to ioc not operational[  220.606735] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=1)[  221.607371] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=2)[  222.608015] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=3)[  223.608648] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=4)[  224.609283] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=5)[  225.609923] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=6)[  226.610559] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=7)[  227.611199] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=8)[  228.611834] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=9)[  229.612474] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=10)[  229.612476] mpt3sas0: _ctl_do_mpt_command: failed due to ioc not operational[  230.613110] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=1)[  231.613748] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=2)[  232.614385] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=3)[  233.615022] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=4)[  234.615660] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=5)[  235.616284] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=6)[  236.616936] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=7)[  237.617572] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=8)[  238.618210] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=9)[  239.618848] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=10)[  239.618850] mpt3sas0: _ctl_do_mpt_command: failed due to ioc not operational


    Also bleibt nur noch der Controller bzw. beide REXP als Fehler übrig....


    Mir ist noch aufgefallen das bei dem neuen Server, welchen ich wie oben beschrieben von der Firmware 4.2.2. auf die Firmware 4.2.5.
    upgegradet habe, beim booten wird jedoch der Treiber der alten Firmware vom Flashspeicher (DoM) geladen, wie man hier erkennen kann:


    Code
    [   25.367620] mpt3sas0: failure at /root/daily_build/4.2.2/NasDriver/drivers/mpt3sas-8.00.00.00/mpt3sas_scsih.c:5948/_scsih_sas_host_add()!


    Ich nehme an das der Flashspeicher (DoM) sich tatsächlich erst aktualisiert, wenn der Server mit der "neuen" 4.2.5 Firmware gebootet hat und dann auf Werkseinstellung gesetzt wird oder wirklich erst nachdem man ein Firmware Recovery ausgeführt hat. Da der neue Server nie die Firmware 4.3.x gesehen hat wird es wohl auch nicht daran liegen das der Fehler nach wie vor präsent ist.


    Ich habe übrigens mit der Hilfe QNAP Sales Deutschland geschafft, das mir ein SAS-Controller aus der Niederländischen QNAP Zentrale zugesendet wird, der dann hoffentlich Anfang der nächsten Woche eintrifft. Der QNAP Vertriebler bei meinen Großhändler konnte mir ebenfalls noch einen SAS-Controller vermitteln. Vielen Dank an der Stelle!!! Mit etwas Glück läuft das Setup Anfang nächster Woche wieder, wenn die Controller & REXP da sind.

  • Ich nehme an das der Flashspeicher (DoM) sich tatsächlich erst aktualisiert, wenn der Server mit der "neuen" 4.2.5 Firmware gebootet hat

    Das NAS bootet immer aus dem DOM. Der DOM wird direkt bei einem FW-Update beschrieben/aktualisiert.

  • Wenn das so ist, wieso wird dann nach dmesg ein Treiber aus der 4.2.2 Firmware geladen obwohl auf 4.2.5 aktualisiert wurde?


    Mir ist klar das die Firmware aus dem DoM bootstrapt auf die HDD`s - was mir nicht klar war ist zu welchen Zeitpunkt der Treiber für den SAS-Controller geladen wird. Diese Frage konnte ich mir aber selbst beantworten durch die dmesg Ausgabe = bereits vor dem bootstrapping.
    Das führte mich zur Frage warum dieser Treiber noch auf der Version 4.2.2 ist.

  • Das wird dir nur QNAP beantworten können. Was du in der Meldung siehst, ist der Build-Pfad zum Kompilierungszeitpunkt.

  • Nach 10 Tagen Downtime von 150TB Storage kann ich endlich sagen "Es läuft wieder" - der SAS-Controller war es.


    Ob der SAS-Controller aber jetzt einen Hard- oder Softwarefehler hat - ist mir immer noch nicht klar. Von Qnap Support habe ich bis heute immer noch keine hilfreichen Erkenntnisse bekommen, hoffe aber das irgend jemand bei Qnap herauszufinden möchte was es jetzt genau war auch wenn das Ticket mit meinen letzten Post dort erledigt ist.


    Vielleicht wird meine Idee angenommen in das Diagnose Tool einen Hardwaretest mit einzubauen, der dann merkt was kaputt ist.
    Jetzt noch die ausstehende REXP1620 wieder abbestellen (zum Glück?! noch im Verzug). Wenn der 2.te SAS- Controller kommt diesen verbauen und das Setup splitten damit so etwas nicht mehr passiert + mir noch einen SAS-Controller ins Lager legen. Dann nur noch den defekten Controller einsenden (5 Monate alt).


    Fazit:
    Entweder die eingesetzte Hardware hoch redundant bauen & Ersatzhardware selbst lagern und nach dem Baukasten Prinzip Teile bei Fehler austauschen oder auf bewährte Hardware in diesen Segment setzen, wo Support & Hardwareverfügbarkeit im Fehlerfall gegeben sind.


    Aber nach der ganzen unbezahlten Zeit & Kosten fahr ich bei den Wetter jetzt an den See und gönne mir ein kaltes Bier!


    In diesen Sinne danke an das Forum & schönes Wochenende!

  • Update vom QNAP Workshop in DÜsseldorf heute!


    Ich habe gerade mit Hr. Florian Schorn gesprochen und ich habe mich sehr gefreut das mein Problem mit dem SAS-Controller im nachhinein mit dem Fehlerhaften ein gesendeten Controller noch aufgeklärt wurde.


    Die Hardware war OK! Die Firmware des Controllers war die Ursache des Problems, es gibt nun ein Tool um die Firmware des SAS-Controller via WebGUI zu aktualisieren - leider ist das Tool nicht öffentlich! Wer dieses Problem auch haben sollte, wendet sich am besten direkt an den QNAP Support und nimmt Bezug auf diese Problematik (SAS-Controller Firmware Fehler).