Hallo zusammen,

 

ich habe seit ein paar Tagen das Problem, dass sich ein paar meiner Docker-Container von alleine ausschalten und sich dann nichtmehr anschalten lassen. Meldung: Error 403 bzw Server Error...

 

Nach einem Reboot geht dann alles wieder (für ein paar wenige Stunden).

Kann mir jemand helfen? Infos im Anhang

 

Vielen Dank!

spacetaxi-diagnostics-20210216-1440.zip

Moin.

 

Für mich sieht es so aus als ob Deine Kingston SSD einen Hau weg hat. (Errors on /dev/ssd1)

Ich würde die mal tauschen.

 

Gruß aus Hamburg,

JoergHH

Dank Jörg, für Deine schnelle Info

 

Kann ich einfach das Cache-Drive wegmachen?

Ich hab da mal im Wiki einen Eintrag gefunden, aber davor hab ich bissel bammel, weil ich nicht alles so richtig übersetzt bekommen habe

Ich hätte noch eine 500GB M.2 SSD die ich opfern könnte...

 

Gibts da noch andere Tips, wie ich das Cache-Drive ersetze?

 

Grüße aus Baden-Baden

1 hour ago, vomi21 said:

Kann ich einfach das Cache-Drive wegmachen?

Ja:

Shares beim Cache auf "Yes" stellen, Docker+VM deaktivieren und den Mover starten, damit er die Dateien auf die HDDs verschiebt.

 

Sobald die SSD leer ist, kannst du das Array stoppen / Server herunterfahren und die SSD ausbauen.

Vielleicht überprüfst Du erst mal, ob die SSD nicht einfach nur fehlerhaft im System integriert und selbst eigentlich okay ist.

Daher würde ich zunächst

1. die SSD an einen anderen SATA-Port am Mainboard anschließen
2. die SSD an eine andere Stromversorgung anschließen
3. andere Kabel als bisher für die o. g. Punkte verwenden.

Dabei immer schön der Reihe nach vorgehen, d. h. erstmal eine Maßnahme durchführen, das Gesamtsystem einige Zeit (Tage?) laufen lassen und gucken, ob das Problem erneut auftritt.

Ich hatte ein solches Phänomen auch schon zweimal, da war das docker Image defekt.

Einfach docker stoppen, docker.img löschen und die docker neu einrichten (unter Apps > previously Installed deine docker anhaken und "install" - fertig)

 

Ich muss aber zugeben dass ich mir deine Diagnostics nicht angesehen habe...

Ich hänge mir hier mal dran.. Bei mir sind heute (nachdem der Mover ziemlich lange lief und ich gestern ein paar Änderungen bei den EInstellungen der Shares gesetzt habe) fast alle Docker Container nicht mehr lauffähig. Teilweise kommt der Fehler 403 aber auch manchmal nur "Bad Parameters".

 

Im Log kommt mir der folgende Eintrag von meiner Cache NVME komisch vor:

Jan 19 13:31:34 M720q kernel: pcieport 0000:00:1b.0: AER: Corrected error received: 0000:01:00.0
Jan 19 13:31:34 M720q kernel: nvme 0000:01:00.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID)
Jan 19 13:31:34 M720q kernel: nvme 0000:01:00.0:   device [15b7:5006] error status/mask=00000001/0000e000

 

 

12 hours ago, independence said:

AER: Corrected error

Die NVMe macht ASPM Probleme. Sie schläft ein, wacht aber nicht mehr auf oder zu spät und damit sind keine Dateien mehr lesbar und alles schmiert ab.

 

Welches Modell verwendest du?

Na das hört sich ja super an..

Es ist eine WD Black SN750. Ist das eher ein Fehler bei den Einstellungen, ein Defekt der Ssd oder eine Inkompatibilität? 

 

Noch ne Info. Der Eintrag taucht im Log ca jede Minute auf.

Edited January 20, 20233 yr by independence

4 hours ago, independence said:

Inkompatibilität

Sozusagen:

https://forums.unraid.net/topic/109990-kein-spindown-nach-hardwareaustausch-mit-aktiviertem-powertop/?do=findComment&comment=1026914

18 hours ago, independence said:

Jan 19 13:31:34 M720q kernel: pcieport 0000:00:1b.0: AER: Corrected error received: 0000:01:00.0

Kannst du bitte mal das probieren:

 

56 minutes ago, mgutt said:

Sozusagen:

https://forums.unraid.net/topic/109990-kein-spindown-nach-hardwareaustausch-mit-aktiviertem-powertop/?do=findComment&comment=1026914

Oh man.. Leider äußerst nervig wie intensiv man recherchieren muss bevor man sich für Komponenten entscheidet.. In meinem Fall hatte ich die Ssd jedoch noch. Evtl muss ich die dann jetzt austauschen. Was genau wird denn beeinträchtigt am System wenn ich die eingebaut lasse? Stromverbrauch? Performance? Sonstige Fehler? 

 

@ich777mach ich und melde mich

@ich777

 

Bevor ich jetzt gleich nen katastrophalen Fehler mache, hier nochmal zur Sicherheit ein Bild der Config. Bin nämlich auch nicht zuhause und mache alles remote ohne die Möglichkeit da gleich groß einzugreifen wenn alles auf die Bretter geht

Edited January 20, 20233 yr by independence

24 minutes ago, independence said:

hier nochmal zur Sicherheit ein Bild der Config.

Nein, so nicht.

 

Mach es doch über die GUI, geh auf den Main Tab, dann klickst du auf Flash (blauer Text) dann scrollst ein wenig runter und fügst folgendes bei deiner Standard Boot Methode (sollte Grün sein) ein:

pci=noaer

 

Sollte dann ca. so aussehen:

(sieht bei dir natürlich anders aus weil du andere Parameter drin hast)

 

Danach musst du den Server rebooten.

26 minutes ago, independence said:

hier nochmal zur Sicherheit ein Bild der Config.

und bei Gelegenheit ... warum hast du alle PCI overrides aktiv ? brauchst du das ?

 

macht nur Sinn wenn die Standard nicht greifen und du iommu splitten musst, etwas mit passthrough nicht funktioniert ...

ich gehe jetzt mal davon aus dass es hierfür einen Grund gab, aber förderlich ist das nicht immer ...

 

Jetzt nichts für remote zu basteln sofern du passthrough's aktiv hast

@ich777

Danke für die Hilfe. Seit ner Stunde läuft unraid nun wieder nach der Änderung der Parameter. Bislang kein Eintrag im Log dazu und alles sieht einwandfrei aus. Ich beobachte das natürlich weiter und halte euch auf dem Laufenden sofern sich was verändert.

Kann es denn durch den Parameter jetzt sein, dass es einfach aufgrund des ausgeschalteten Reportings nicht mehr im Log auftaucht aber dennoch der gleiche Fehler mit der Ssd vorhanden ist?

11 minutes ago, independence said:

Kann es denn durch den Parameter jetzt sein, dass es einfach aufgrund des ausgeschalteten Reportings nicht mehr im Log auftaucht aber dennoch der gleiche Fehler mit der Ssd vorhanden ist?

Bitte lies im den verlinkten Thread weiter den ich gepostet habe.

 

Das ist ein Bug im Kernel und die Fehlermeldung sollte im engeren Sinn gar nicht angezeigt werden bzw. die Fehlermeldung zeigt nicht nur vermeidlich einen Fehler sondern verursacht eigentlich Probleme bzw. mehr Probleme.

33 minutes ago, independence said:

Kann es denn durch den Parameter jetzt sein, dass es einfach aufgrund des ausgeschalteten Reportings nicht mehr im Log auftaucht aber dennoch der gleiche Fehler mit der Ssd vorhanden ist?

So sehe ich das auch.

 

AER Fehler zu unterdrücken ist genauso wenig sinnvoll wie CRC Fehler einer SATA Disk zu ignorieren.

 

Es gab ja einen Fehler bei der Übertragung der Daten, der dank der Checksumme erkannt und dann korrigiert wurde. Ich sehe hier keinen Bug im Kernel. Tatsächlich wurden bei zahlreichen SSD Modellen im Kernel Listen geführt, wo bestimmte Funktionen deaktiviert werden:

https://www.heise.de/hintergrund/c-t-wirkt-Problematische-SSD-im-Bauvorschlag-fuehrt-zu-Bugfix-im-Linux-Kernel-5074713.html

 

Bei der Kingston wurde zb NVME_QUIRK_NO_DEEPEST_PS gesetzt.

 

Der Bug ist also wenn überhaupt in der Firmware der NVMe zu suchen.

 

Ich würde daher den Ansatz verfolgen den tiefsten Schlafzustand der NVMe zu deaktivieren. Also was in meinem Link weiter unten gemacht wurde.

Wäre natürlich auch möglich das ich mal teste den Parameter im Kernel zu setzen. Da ich kein Ahnung habe wie und vor allem wo ich das mache muss das aber noch einige Tage warten

15 minutes ago, mgutt said:

AER Fehler zu unterdrücken ist genauso wenig sinnvoll wie CRC Fehler einer SATA Disk zu ignorieren.

Das sind keine wirklichen Fehler, zumindest nicht in meinen Augen und die werden Normalerweise korrigiert vom PCIe BUS. Das Problem ist das diese Meldung allein einen Schlimmeren Fehler auslösen wenn sie auftreten/angezeigt werden und die PCIe Express Geräte dadurch beeinträchtigt werden.

 

Genau wegen dem was du oben bestätigt hast werden die ausgelöst, zumindest aus meiner Erfahrung und was ich bis jetzt gesehen habe:

5 hours ago, mgutt said:

Sozusagen:

...Inkompatibilität.

 

17 minutes ago, mgutt said:

Der Bug ist also wenn überhaupt in der Firmware der NVMe zu suchen.

...oder auch vom Motherboard.

 

18 minutes ago, mgutt said:

Ich würde daher den Ansatz verfolgen den tiefsten Schlafzustand der NVMe zu deaktivieren. Also was in meinem Link weiter unten gemacht wurde.

Das hat doch schon in zwei bzw. mehreren Threads von Früher nichts gebracht oder irre ich mich hier? Tritt das nicht vermehrt auf Gigabyte Boards auf wenn ich mich nicht irre...?

Ich hab generell nix gegen Gigabyte aber mir kommen die nicht mehr ins Haus, muss aber auch BTW sagen das ich ein ASUS Board hab und das nur von meinen Digital Devices Karten ausgelöst wird...

 

14 minutes ago, independence said:

Wäre natürlich auch möglich das ich mal teste den Parameter im Kernel zu setzen.

Du kannst beides probieren, aber im verlinkten Thread hat es nicht funktioniert soweit ich bis jetzt gesehen hab.

Ich würde dir jetzt mal raten es so zu lassen wie du es hast nach ein paar Tagen machst du dann einen Scrub bzw. eine Dateisystemüberprüfung und dann kannst du den anderen Parameter Probieren.

 

Ich vermute eher ein Problem mit dem Sleep der NVME SSDs und das sie um ein paar ns zu spät wieder online sind bzw. das kann aber Ursachen in der Firmware der NVME haben, kann auch ein Problem in der integration im BIOS oder ein Hardware Design Problem sein (vom Gerät selbst oder vom Motherboard).

1 hour ago, ich777 said:

Das sind keine wirklichen Fehler

Sehe ich nun mal anders

 

1 hour ago, ich777 said:

...oder auch vom Motherboard.

Das kann damit zusammenhängen, aber in den meisten Fällen ist es einfach ASPM. Gigabyte ist hier präsenter, weil sie nicht wie andere Hersteller hingehen und einfach Schlafzustände vollständig deaktivieren. Siehe zb Asrock, wo viele Boards nicht unter C7 gehen. Da hat man weniger Probleme, zeugt aber eher von Inkompetenz.

 

1 hour ago, ich777 said:

aber im verlinkten Thread hat es nicht funktioniert soweit ich bis jetzt gesehen hab.

Ich denke viele wenden den Wert nicht korrekt an. Dieser ist individuell zu ermitteln, da bei jedem NVMe Modell anders.

 

Hatte ich hier erklärt:

 

 

Oder man deaktiviert ASPM der NVMe komplett:

 

nvme_core.default_ps_max_latency_us=0

 

Das wäre zumindest ein Versuch wert.

 

 

1 hour ago, mgutt said:

Sehe ich nun mal anders

Aber hast du dir denn mal alles durchgelesen? Vermutlich nicht sonst wüsstest du das dort immer Corrected dabei steht.

 

1 hour ago, mgutt said:

Gigabyte ist hier präsenter, weil sie nicht wie andere Hersteller hingehen und einfach Schlafzustände vollständig deaktivieren.

Starke Aussage, ich sage hier eher das es eine eher schlechte Integration ist im BIOS, auch wenn sie es anbieten...

 

1 hour ago, mgutt said:

Ich denke viele wenden den Wert nicht korrekt an. Dieser ist individuell zu ermitteln, da bei jedem NVMe Modell anders.

Aber es waren bis jetzt bei allen Gigabyte und WD, also vermute ich das die Kombination das Problem verursacht.

 

 

Lies dir bitte nochmal durch was ich geschrieben habe, die Meldung allein Löst einen Fehler aus der viel Kritischer ist und die Funktion des PCIe Geräts verursacht, kann man ja mal überlesen...

On 1/20/2023 at 3:10 AM, independence said:

Na das hört sich ja super an..

Es ist eine WD Black SN750. Ist das eher ein Fehler bei den Einstellungen, ein Defekt der Ssd oder eine Inkompatibilität? 

 

Noch ne Info. Der Eintrag taucht im Log ca jede Minute auf.

 

Hier zitiere ich mich mal noch selbst. Ich habe die gleiche NVMe SSD nun in ein Asustor Lockerstor 4 Gen 2 eingebaut und ich bekomme keine Fehlermeldungen im Log angezeigt. Also mag es nicht ausschließlich an der SN750 liegen sondern eher am Zusammenspiel mit der CPU und/oder dem Mainboard.

40 minutes ago, independence said:

Also mag es nicht ausschließlich an der SN750 liegen sondern eher am Zusammenspiel mit der CPU und/oder dem Mainboard.

das wurde ja auch bereits mehrfach in diversen Threads schon durchgekaut ... auch ich nutze eine SN750 ohne jegliche Probleme ... was aich in dem ein oder anderen Thread bereits beschrieben hatte, es liegt fast immer an einer "individuellen" Konstellation ...

 

 

0 errors im log ....