Screenfreeze

[FoersterWS]

Hallo,

ich habe eine SoftSPS mit Codesys unter Debian auf einem PanelPC mit Touchscreen eingerichtet. Prinzipiell funktioniert alles. Allerdings kommt es sporadisch vor, dass das System komplett einfriert. Der Touchscreen lässt sich nicht mehr bedienen und auch per Netzwerk kann das System nicht mehr erreicht werden.
Gibt es hier vielleicht jemanden, der anhand von Logdateien herausfinden kann, wo das Problem liegt? Welche Dateien wären dafür von Nöten?

Ich habe grundlegende Linux-Kentnisse als Nutzer. In die Tiefen des Systems verirre ich mich aber nur selten.

Vielen Dank im Voraus.

Hardware:
Panelmaster 1581, 15", J1900, 4GB, 120GB
Dieser 15" Panel PC mit resistivem Touchscreen und stromsparendem Intel® Celeron® J1900 SoC Prozessor mit 2.0GHz überzeugt vor allem durch ein optimiertes Preis-Leistungs-Verhältnis. Eine ausgewogene Mischung aus qualitativ hochwertigen Materialien und Komponenten sind in dieser Preisklasse sonst nur schwer zu finden. Seine Hauptmerkmale sind ein robustes und markant gestaltetes Aluminiumgehäuse mit IP65 Frontschutz, eine schnelle und hochwertige 120GB SSD, bis zu 8GB RAM, überdurchschnittlich viele, sowie ausgewogene Anschlüsse und das alles zu einem geringen Anschaffungspreis. Natürlich wurde bei der Hardware auf die für die Industrie übliche Langzeitverfügbarkeit geachtet und verspricht so eine langfristig rentable Investition.
Lüfterlos: ja Displaygröße: 15" Touchscreen: resistiv Prozessor: Intel® Celeron® J1900 SoC 2.0GHz RAM: 4.00GB max. RAM: 8.00GB Laufwerk: SSD Laufwerkskapazität: 120.0GB Slotarten: MiniPCIe Gigabit LAN: 2 WLAN: optional Serielle Schnittstellen: 6 davon als RS232 nutzbar: 6 davon als RS485 nutzbar: 1 USB 2.0: 3 USB 3.0: 1 Digital I/O: 0 IP-Schutz komplett: ohne IP-Schutz Front: IP65 Betriebstemperatur: 0 - 50°C Einbau: VESA 100, Paneleinbau Breite: 395mm Tiefe: 82mm Höhe: 313mm Material: Aluminium

[MSfree]

Panelmaster 1581, 15", J1900, 4GB, 120GB
Dieser 15" Panel PC mit resistivem Touchscreen und stromsparendem Intel® Celeron® J1900 SoC Prozessor mit 2.0GHz überzeugt ...

Boah, dieses Produktwerbegeschwalle hättest du nun nicht wirklich kopieren brauchen.

Der J1900 hat einen Bug, der in einem der Stromsparstati zu finden ist, im Speziellen im C6-Status. Intel empfiehlt folgendes:

https://howto.lintel.in/freezing-intels ... ned-patch/

[FoersterWS]

Vielen Dank für den Hinweis.

Ich werde den Patch gleich mal ausprobieren.

[hikaru]

Ich werde den Patch gleich mal ausprobieren.

Der "Patch" ist ein Shell-Script, das bei jedem Boot ausgeführt werden muss, am besten so früh wie möglich, bevor die CPU in die Verlegenheit kommt, in den C6-State zu fallen.

Das war dann wohl nix [1]:

Einige Anwender berichten aber auch, dass die Probleme mit Kernel 4.7 auch ohne den Patch auf ihrer Hardware nicht mehr auftreten.

[1] https://www.golem.de/news/intel-einfrie ... 23546.html

[FoersterWS]

OK, habe den Scriptaufruf jetzt in die /etc/crontab gepackt (

Code: Alles auswählen

@reboot    /home/user/c6off+c7on.sh

).

Kernel ist 4.19.0. Das System ist offline. Die Installtion lief ausschließlich über die DVD-Images.
Ein missglückter Energiesparmodus passt zur Symptomatik (Freezing tritt auf, wenn einige Zeit keine Benutzerinteraktion vorliegt). Die SoftSPS scheint nicht genügend last zu sein um den Energiesparmodus komplett zu unterdrücken.

Ich werde die Anlage mal über Nacht an lassen und schauen, wie es morgen aussieht.

[MSfree]

Sollte der Aufruf des Skripts keine Abhilfe schaffen, kann man mit einem Kernelparameter die C-States auch abschalten. In meinem Link oben ist auch erklärt, wie das geht, ich zitiere den Absatz hier nochmal:

The problem occurs when the system enters sleep mode C-State 6 (C6) after an interrupt service routine (ISR) is started but before it is terminated and the program continues at the interrupted location. A previously used workaround was to set the processor to C state 1 by passing the intel_idle.max_cstate=1 parameter to the kernel . However, this leads to increased energy consumption and thus to shorter battery life.

Der hier erwähnte steigende Energieverbrauch ist jedoch nicht von großer Bedeutung, das macht im Leerlauf vielleicht 1W aus, unter Last ist das ohnehin ohne Belang.

[FoersterWS]

Das Problem ist über Nacht wieder aufgetreten. Kann ich irgendwo überprüfen, dass das Script per Cronjob auch wirklich ausgeführt wurde?

Die Änderung der Kerneleinstellung kommt durchaus in Frage. Wir arbeiten im Netzbetrieb und der Rechner fällt im Vergleich zum Schweißgerät der Anlage sicher nicht weiter ins Gewicht. Leider weiß ich nicht, wie ich dem Kernel diesen Parameter übergebe.

EDIT:
Habe selbst eine Anleitung gefunden. Ich würde also in der Datei /etc/default/grub hinter GRUB_CMDLINE_LINUX= folgendes ergänzen:
intel_idle.max_cstate=1

Ist das korrekt?

[MSfree]

Das Problem ist über Nacht wieder aufgetreten. Kann ich irgendwo überprüfen, dass das Script per Cronjob auch wirklich ausgeführt wurde?

Du kannst prüfen, ob die C-States (C6) abgeschaltet sind. Das Skript schreibt Einsen in die Kernelvariablen

Code: Alles auswählen

/sys/devices/system/cpu/cpu?/cpuidle/state6/disable

und Nullen in die

Code: Alles auswählen

/sys/devices/system/cpu/cpu?/cpuidle/state7/disable

Mit

Code: Alles auswählen

cat /sys/devices/system/cpu/cpu?/cpuidle/state6/disable

sollte also Einsen in der Ausgabe stehen.
Mit

Code: Alles auswählen

cat /sys/devices/system/cpu/cpu?/cpuidle/state7/disable

sollten Nullen in der Ausgabe stehen.

Habe selbst eine Anleitung gefunden. Ich würde also in der Datei /etc/default/grub hinter GRUB_CMDLINE_LINUX= folgendes ergänzen:
intel_idle.max_cstate=1

Ist das korrekt?

Ja, die Zeile in /etc/default/grub sollte so aussehen:

Code: Alles auswählen

GRUB_CMDLINE_LINUX="intel_idle.max_cstate=1"

Danach ist noch

Code: Alles auswählen

update-grub

und danach ein reboot auszuführen.

Als letzter Rettungsanker könnte auch das BIOS/UEFI dienen. Dort kann man in der Regel auch die C-States steuern, in dem man z.B. den maximalen C-State auf 5 setzt.

[FoersterWS]

Die cpustates, die ich mit cat ... aulsesen sollte gehen nur bis zur 5, c6 und c7 gibt es dort nicht. Insofern überrascht es auch nicht, dass das Script nicht wirkt.

Ich versuche jetzt die Variante im Kernel und lasse die Anlage wieder über Nacht stehen. Wenn das nicht hilft suche ich im BIOS. Vielen Dank bis hierhin. Mit so schnellen, so hilfreichen Antworten hatte ich gar nicht gerechnet.

[FoersterWS]

Es war die ganze NAcht an, und läuft noch. Der Kernel-Parameter scheint es gebracht zu haben.

Vielen Dank nochmal.