Dies ist eine mögliche PSA: Ich habe nicht bestätigt, dass das Update von File Station 5 tatsächlich den Neustart des NAS verursacht hat. Es war nur so, dass der NAS etwa eine Stunde nach dem Update plötzlich neu gestartet wurde. Ich habe ein Ticket beim Support eröffnet, damit sie die Protokolle überprüfen und feststellen können, ob das Problem dadurch verursacht wurde oder ob etwas anderes passiert ist.
Es handelte sich um File Station 5 5.5.6.5208_20260310 auf QUTS 5.2.8.3359 Firmware
Unser TVS-1688x hat sich gelegentlich neu gestartet. Ich habe den Arbeitsspeicher mit einem anderen NAS getauscht (beide verwenden Kingston Server-RAM – so gut wie es nur geht. Eine Charge hatte Micron, die andere Hynix). Ich habe nie ein Ticket eröffnet, weil es so selten vorkam und ich dachte, es wäre schwer zu isolieren. Außerdem würde mich der Support vermutlich mit Maßnahmen wie RAM-Tests beschäftigen, obwohl ich weiß, dass es nicht am RAM liegt.
In vielen Fällen haben fehlerhafter oder inkompatibler RAM Neustarts verursacht, daher ist das für die Fehlersuche kein schlechter Ansatz. (Die meisten NAS verwenden außerdem keinen ECC-RAM)
Normalerweise läuft das NAS 24x7 über Monate hinweg. Ich fahre es in der Regel nur für Firmware-Updates herunter, und der Ablauf, dem ich folge, ist: Update – es fordert einen Neustart an, dem ich zustimme, Update und Hochfahren, Herunterfahren und für 30 Sekunden vom Strom nehmen und dann wieder starten.
Es ist für mein System nicht normal, einfach so aus heiterem Himmel neu zu starten. Der einzige Fehler, der im Qlog gemeldet wird, ist Warnung 2026-03-16 13:19:25 — — localhost — Stromversorgung NAS-Stromstatus [Stromversorgung] Das System wurde beim letzten Mal nicht ordnungsgemäß heruntergefahren.
Der Support hat sich bei mir gemeldet und mitgeteilt, dass es anscheinend nicht am File Station-Update liegt, da der Neustart erst drei Stunden später erfolgte. Sie arbeiten derzeit an einer Ursachenanalyse.
Ignoriert vorerst meine PSA bezüglich des File Station-Updates.
Wenn sie es herausfinden, sag mir Bescheid.
Der Support hat sich bei mir gemeldet, es lag nicht an der Software, sondern an einer Art Hardwareproblem.
Nachfolgend deren Analyse zu Ihrer Information in dieser Angelegenheit:
BERT-Analyse:
Das System erlebte einen Host-Reset, ausgelöst durch ein TCO (Watchdog) Timeout, was bedeutet, dass die CPU/der Kern über einen längeren Zeitraum nicht reagierte (reagierte nicht auf SMI-Interrupts).
Es gibt PCIe- / Controller-Ebene-Fehler:
Receiver Error (Port0) → weist auf ein Signalintegritäts- oder Hardware-Kommunikationsproblem hin.
Replay Timer Timeout (Port2) → deutet auf Paket-Neuübertragungsfehler / Linkinstabilität hin.
Aufgrund dieser kombinierten Probleme stellte das System fest, dass es sich in einem kritischen, nicht wiederherstellbaren Zustand befand, was zu Folgendem führte:
Plattformabsturz
Erstellung eines Crash-Logs
Dies ist ein Hardware-Instabilitätsproblem, das höchstwahrscheinlich zusammenhängt mit:
Problemen mit PCIe-Gerät / Controller
Möglicherweise fehlerhaftes Kabel, Slot oder Gerät
Firmware- oder Treiberinstabilität (weniger wahrscheinlich, aber möglich)
Kurz gesagt:
System hängt → PCIe-Fehler → Watchdog-Timeout → erzwungener Host-Reset → Crash-Log erstellt.Hinweis: Wir sollten dieses System ggf. überwachen, indem wir den Watchdog-Timer deaktivieren, falls das Problem erneut auftritt. Bitte informieren Sie uns, falls dies wiederkehrt.
Ich denke, mein KVM-Switch, den ich eingerichtet hatte, um einen Monitor/Tastatur zwischen NAS und Mini-PC zu teilen, verursachte das Hardwareproblem. Der KVM hat dazu geführt, dass der Mini-PC eingefroren und ein Bluescreen angezeigt wurde. Nachdem ich das Video vom KVM entfernt hatte, lief der Mini-PC problemlos. In meinem Fall scheint also der externe KVM defekt zu sein.
TVS-h1688X Nach Jahren, in denen dies gelegentlich auftrat, passiert es nur, wenn der HDMI-Anschluss verwendet wird.