Debian 10.x: X-Server friert ein - Ursache nicht lokalisiert

KDE, Gnome, Windowmanager, X11, Grafiktreiber und alles was dazu notwendig ist. Schau auch in den "Tipps und Tricks"-Bereich.
Benutzeravatar
prox
Beiträge: 371
Registriert: 08.07.2019 18:50:34
Lizenz eigener Beiträge: GNU General Public License

Re: Debian 10.x: X-Server friert ein

Beitrag von prox » 06.05.2021 12:46:32

Hi Willy4711,

Nachtrag zu Deinem Beitrag:

Das von mir beobachtete Verhalten tritt auf meinem Laptop mit einem gewissen Grafikchip unter Debian Stable (Buster) mit allen verfügbaren Debian-Updates für Buster auf, mit dem jeweils aktuellen, offiziellen Release von Firefox seit Version 88.0.

Du hast das Verhalten unter Debian Unstable (Sid) mit Firefox-Betaversionen beobachtet.

Damit hast Du das von mir beobachtete Verhalten nicht unter den gleichen Voraussetzungen beobachtet wie ich.

Wollte da nur vorsorglich drauf hinweisen, auch für die anderen User.

prox

mcb

Re: Debian 10.x: X-Server friert ein - Firefox wahrscheinlich die Ursache

Beitrag von mcb » 06.05.2021 13:34:26

prox hat geschrieben: ↑ zum Beitrag ↑
06.05.2021 12:38:12
OrangeJuice hat geschrieben: ↑ zum Beitrag ↑
06.05.2021 10:15:11
Flatpak hat eine Sandbox aktiviert.
Die Sandbox kann ich auch im Firefox, der einer tar.bz2-Datei entstammt, konfigurieren über den Schlüssel "security.sandbox" in der about:config-Seite. Für Details siehe z. B. https://wiki.mozilla.org/Security/Sandb ... n_Settings

Aber was soll mir eine Sandbox hier in diesem Falle überhaupt bringen? Das Verhalten wird wahrscheinlich durch Firefox selbst verursacht, aber wahrscheinlich nicht durch Webseiten, die ich mit dem Firefox besuche.
Ich würde das Flatpak mal probieren - da gibt es schon Unterschiede -

läuft den der Firefox-ESR ?!?

Benutzeravatar
prox
Beiträge: 371
Registriert: 08.07.2019 18:50:34
Lizenz eigener Beiträge: GNU General Public License

Re: Debian 10.x: X-Server friert ein - Firefox wahrscheinlich die Ursache

Beitrag von prox » 06.05.2021 14:42:29

mcb hat geschrieben: ↑ zum Beitrag ↑
06.05.2021 13:34:26
Ich würde das Flatpak mal probieren - da gibt es schon Unterschiede -
Hm, ich würde aber erstens gerne bei der deb-Paketverwaltung bleiben (kann das gleichzeitige Vorhalten von Flat- und deb-Paketen nicht vielleicht zu Problemen führen?), und zweitens würde ich gerne einen Bugreport über das Verhalten entweder bei Debian oder bei Mozilla erstellen, wozu mir aber ausreichende Infos über die Hintergründe des Verhaltens bisher fehlen.
mcb hat geschrieben: ↑ zum Beitrag ↑
06.05.2021 13:34:26
läuft den der Firefox-ESR ?!?
Nein.

Ich implementiere wie gesagt stets die jeweils neueste Firefox-Version als tar.bz2-Datei in /opt

prox

mcb

Re: Debian 10.x: X-Server friert ein - Firefox wahrscheinlich die Ursache

Beitrag von mcb » 06.05.2021 14:48:29

Das habe ich verstanden - es wäre nicht verkehrt mal auszuprobieren ob es mit dem ESR ff von Debian auch auftritt -

Hier laufen alle Firefox Versionen ohne Fehler (deb, /opt, /home oder Flatpak)

Benutzeravatar
prox
Beiträge: 371
Registriert: 08.07.2019 18:50:34
Lizenz eigener Beiträge: GNU General Public License

Re: Debian 10.x: X-Server friert ein - Firefox wahrscheinlich die Ursache

Beitrag von prox » 06.05.2021 15:58:43

mcb hat geschrieben: ↑ zum Beitrag ↑
06.05.2021 14:48:29
Das habe ich verstanden - es wäre nicht verkehrt mal auszuprobieren ob es mit dem ESR ff von Debian auch auftritt -

Hier laufen alle Firefox Versionen ohne Fehler (deb, /opt, /home oder Flatpak)
Stimmt, ich werde mal die ESR-Version probieren, die scheint stabiler zu sein als die "Rapid Release"-Version von Firefox. Ich werde von meinen Beobachtungen berichten, kann aber was länger dauern bis dahin, da die ESR-Version nicht so oft releast wird wie die "Rapid Release"-Version.

Danke für den Hinweis, mcb.

Nachtrag: Benutze jetzt den Firefox-ESR in Version 78.10. Das Verhalten trat im Rapid Release ab Version 88.0 auf. Mal gucken, was passiert, wenn die ESR-Version die Version 88.0 oder größer erreicht - wird dann das Verhalten wieder auftreten? Bis dahin kann es aber eine Weile dauern.

Benutzeravatar
prox
Beiträge: 371
Registriert: 08.07.2019 18:50:34
Lizenz eigener Beiträge: GNU General Public License

Re: Debian 10.x: X-Server friert ein - Firefox wahrscheinlich die Ursache

Beitrag von prox » 06.05.2021 20:14:37

Die grafische Oberfläche ist seit meinem letzten Beitrag hier im Thread zwei Mal eingefroren.

Das erste Mal war der FF (ESR-Version) geöffnet, zusammen mit Kontact und Zoom.

Das zweite Mail war der FF nicht geöffnet, sondern nur Kontact und Zoom.

Die Ursache für das Einfrieren der grafischen Oberfläche kann also nicht auf den Firefox zurückgeführt werden.

Liegt hier vielleicht ein Hardwarefehler vor? Am RAM kann es wohl nicht liegen, denn wenn das Verhalten auftritt, kann ich ja immer noch auf eine Konsole wechseln und erfolgreich dort den Reboot-Befehl ausführen.

Hat der Grafikchip vielleicht einen Hardware-Fehler?

Oder liegt die Ursache für das Verhalten dann doch im Xorg-Server?

Benutzeravatar
prox
Beiträge: 371
Registriert: 08.07.2019 18:50:34
Lizenz eigener Beiträge: GNU General Public License

Re: Debian 10.x: X-Server friert ein - Ursache nicht lokalisiert

Beitrag von prox » 06.05.2021 21:53:24

Update: Vielleicht ist mein Laptop auch einfach zu verdreckt, weswegen die CPU heiß läuft. Deswegen werde ich morgen mal den Lüfter an meinem Laptop absaugen. Der Laptop ist 7 Jahre alt und bisher noch nie dieser Prozedur unterzogen worden.

mcb

Re: Debian 10.x: X-Server friert ein - Ursache nicht lokalisiert

Beitrag von mcb » 07.05.2021 11:25:57

prox hat geschrieben: ↑ zum Beitrag ↑
06.05.2021 21:53:24
Update: Vielleicht ist mein Laptop auch einfach zu verdreckt, weswegen die CPU heiß läuft. Deswegen werde ich morgen mal den Lüfter an meinem Laptop absaugen. Der Laptop ist 7 Jahre alt und bisher noch nie dieser Prozedur unterzogen worden.
Wärmeleitpaste erneuern gäbe es auch noch. :mrgreen:

Benutzeravatar
prox
Beiträge: 371
Registriert: 08.07.2019 18:50:34
Lizenz eigener Beiträge: GNU General Public License

Re: Debian 10.x: X-Server friert ein - Ursache nicht lokalisiert

Beitrag von prox » 07.05.2021 11:57:43

mcb hat geschrieben: ↑ zum Beitrag ↑
07.05.2021 11:25:57
Wärmeleitpaste erneuern gäbe es auch noch. :mrgreen:
Ja, davon hat mir jemand gestern Abend auch berichtet. Ob ich das könnte? Vielleicht dann besser zur Reparatur geben, das Gerät.

mcb

Re: Debian 10.x: X-Server friert ein - Ursache nicht lokalisiert

Beitrag von mcb » 07.05.2021 12:14:46

prox hat geschrieben: ↑ zum Beitrag ↑
07.05.2021 11:57:43
mcb hat geschrieben: ↑ zum Beitrag ↑
07.05.2021 11:25:57
Wärmeleitpaste erneuern gäbe es auch noch. :mrgreen:
Ja, davon hat mir jemand gestern Abend auch berichtet. Ob ich das könnte? Vielleicht dann besser zur Reparatur geben, das Gerät.
Eigentlich und uneigentlich schalten Notebooks hart ab wenn sie Überhitzen (springt ne Kontakt raus) bei ca 100 Grad -

Piezo oder so :?:

Softwareproblem ist wahrscheinlicher.

Benutzeravatar
prox
Beiträge: 371
Registriert: 08.07.2019 18:50:34
Lizenz eigener Beiträge: GNU General Public License

Re: Debian 10.x: X-Server friert ein - Ursache nicht lokalisiert

Beitrag von prox » 07.05.2021 12:17:44

mcb hat geschrieben: ↑ zum Beitrag ↑
07.05.2021 12:14:46
prox hat geschrieben: ↑ zum Beitrag ↑
07.05.2021 11:57:43
mcb hat geschrieben: ↑ zum Beitrag ↑
07.05.2021 11:25:57
Wärmeleitpaste erneuern gäbe es auch noch. :mrgreen:
Ja, davon hat mir jemand gestern Abend auch berichtet. Ob ich das könnte? Vielleicht dann besser zur Reparatur geben, das Gerät.
Eigentlich und uneigentlich schalten Notebooks hart ab wenn sie Überhitzen (springt ne Kontakt raus) bei ca 100 Grad -

Piezo oder so :?:

Softwareproblem ist wahrscheinlicher.
Ok, danke für den Hinweis, mcb.

Benutzeravatar
prox
Beiträge: 371
Registriert: 08.07.2019 18:50:34
Lizenz eigener Beiträge: GNU General Public License

Re: Debian 10.x: X-Server friert ein - Ursache nicht lokalisiert

Beitrag von prox » 15.05.2021 17:27:37

Habe vor 8 Tagen an meinem Laptop den Schacht zu meinem Lüfter abgesaugt.

Nach 7 Tagen fror Xorg wieder ein.

Habe dann mittels des Programms xsensors mir die Temperatur der CPU angeschaut: diese schwankt zwischen 40 und unter 50 Grad - meiner Meinung nach eine normale Temperatur.

Das Programm sensors gibt auf der Konsole aus:

Code: Alles auswählen

coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +46.0°C  (high = +87.0°C, crit = +105.0°C)
Core 0:        +43.0°C  (high = +87.0°C, crit = +105.0°C)
Core 1:        +42.0°C  (high = +87.0°C, crit = +105.0°C
Habe anschließend das RAM-Test-Programm memtest86+ fast 10 Stunden lang laufen lassen - es hat keinen Fehler festgestellt. Die dort angegebene CPU-Temperatur betrug 50 bis unter 60 Grad.

Habe anschließend die von mir hier in diesem Thread im ersten Beitrag erwähnte xorg.conf umbenannt in xorg.old, danach Neustart, und beobachte jetzt, ob das Verhalten wieder auftritt.

Benutzeravatar
prox
Beiträge: 371
Registriert: 08.07.2019 18:50:34
Lizenz eigener Beiträge: GNU General Public License

Re: Debian 10.x: X-Server friert ein - Ursache nicht lokalisiert

Beitrag von prox » 01.06.2021 20:51:50

Update:

Habe letzten Freitag die xorg.old wieder umbenannt in xorg.conf in /etc/X11 (für den Inhalt der xorg.conf siehe der erste Beitrag in diesem Thread) und das Paket xbacklight installiert. Dieses Paket ist meiner Meinung nach dafür zuständig, dass die Anweisungen in der xorg.conf vom X-Server umgesetzt werden können.

Bis eben fror X nicht ein, dann aber schon. Habe nach dem Einfrieren und vor dem Reboot das Ergebnis des Programms dmesg in eine Datei umgeleitet. In dieser Datei fallen die folgenden letzten 5 von 7 Zeilen auf:

Code: Alles auswählen

[  707.615368] ath: regdomain 0x8114 dynamically updated by country element
[  707.655599] wlp3s0: Limiting TX power to 20 (20 - 0) dBm as advertised by e0:28:6d:81:53:b3
[ 3412.114690] perf: interrupt took too long (2516 > 2500), lowering kernel.perf_event_max_sample_rate to 79250
[ 4574.977618] perf: interrupt took too long (3156 > 3145), lowering kernel.perf_event_max_sample_rate to 63250
[ 6097.250000] perf: interrupt took too long (3965 > 3945), lowering kernel.perf_event_max_sample_rate to 50250
[ 8204.685202] perf: interrupt took too long (4962 > 4956), lowering kernel.perf_event_max_sample_rate to 40250
[ 9454.817253] perf: interrupt took too long (6203 > 6202), lowering kernel.perf_event_max_sample_rate to 32000
Kann aus den letzten 5 Zeilen geschlossen werden, dass die Ursache für das Verhalten der installierte Kernel ist? Mein Kernel ist der folgende:
root@punk:~# uname -a
Linux punk 4.19.0-16-amd64 #1 SMP Debian 4.19.181-1 (2021-03-19) x86_64 GNU/Linux
root@punk:~#

peter1969
Beiträge: 743
Registriert: 17.10.2006 08:57:58
Lizenz eigener Beiträge: GNU General Public License
Wohnort: Stuttgart

Re: Debian 10.x: X-Server friert ein - Ursache nicht lokalisiert

Beitrag von peter1969 » 23.06.2021 09:57:53

Eins hab ich nicht ganz verstanden: Benutzt Du bei Debian 10 den Modesetting-Treiber oder den Intel-Treiber? Bei einem meiner Laptops mit Intel-Grafik verursachte der Modesetting-Treiber auch unregelmäßige Abstürze. Der Intel-Treiber löste das Problem. So richtete ich ihn ein:

Erzeuge eine Datei /usr/share/X11/xorg.conf.d/80-mychanges.conf mit folgendem Inhalt:

Section "Device"
Identifier "Intel"
Driver "intel"
Option "TearFree" "true"
EndSection

Dann starte neu und überprüfe den Erfolg mit folgendem Befehl: # sudo grep -e intel /var/log/Xorg.0.log
Wenn der Intel-Treiber benutzt wird, müssen diverse Intel-Einträge erscheinen
Googlet, so werdet Ihr finden. Klicket, so wird Euch aufgetan.

willy4711

Re: Debian 10.x: X-Server friert ein - Ursache nicht lokalisiert

Beitrag von willy4711 » 23.06.2021 11:17:14

Ich habe jetzt gerade die vermeintliche Ursache gefunden. :evil:

Der Verursacher ist Debiandevilspie2 bzw. die Aktionen die ausgeführt werden.

So eine Aktion sieht so aus ~/.config/devilspie2/Firefox.lua):

Code: Alles auswählen

if (get_window_name()=="Mozilla Firefox") then
	-- x,y, xsize, ysize
	set_window_geometry(200,320,2400,1500);
	set_window_workspace(2)
	change_workspace(2)
	
end
Ich habe 6 Arbeitsflächen. Devilspie ordnet diversen Programmen bestimmte Arbeitsflächen zu.
Beim Start eines Programms (FF / Thunderbird / Virtualbox u.A.) wird auf die entsprechende Arbeitsfläche umgeschaltet und
das Programm fokussiert.
Virtualbox startet z.B. auf Arbeitsfläche 6, Wenn ich dann FF starte gibt es ein kurzes Flackern und der Bildschirm springt auf
Arbeitsfläche 2. ----> Patsch
Das ist die häufigste Aktion, die Ich ausführe, deshalb fiel mein Verdacht auch auf den armen FF :P

Jetzt hab ich das mal mit Thunderbird probiert (der ist ja in der Regel immer geöffnet) ---> platsch
Selbst der Start eines Terminals (Umschalten von Arbeitsfläche 6 auf Arbeitsfläche 1) hat diesen Effekt.

Wenn die Programme offen sind, kann ich problemlos von einer Arbeitsfläche zu anderen schalten, ohne das was passiert.

Es scheint also mit dem Start eines (beliebigen) Programms und dem gleichzeitigen Umschalten (change_workspace) auf eine
andere Arbeitsfläche, (gesteuert von Devilspie) zusammenzuhängen.

Voraussetzung ist allerdings, das eine VM läuft. :twisted:
Devispie2 ist im Autostart.

In keinem Protokoll finde ich dazu etwas. Da mir nichts einfällt, wie ich den Fehler beheben kann, bleibt mir
wohl nichts anderes übrig, als aufzupassen :roll: :roll: :roll:

Benutzeravatar
prox
Beiträge: 371
Registriert: 08.07.2019 18:50:34
Lizenz eigener Beiträge: GNU General Public License

Re: Debian 10.x: X-Server friert ein - Ursache nicht lokalisiert

Beitrag von prox » 25.06.2021 16:39:34

Update:

Der Xorg-Server auf dem betroffenen Rechner ist seit zwei Wochen nicht mehr eingefroren. Ich hatte vor zwei Wochen meine erstellte /etc/X11/xorg.conf umbenannt, also deaktiviert. Seitdem ist der Fehler nicht mehr aufgetreten. Problem behoben, könnte man jetzt behaupten, aber:

Der Bildschirminhalt, der vom Xorg-Server bereitgestellt wird, könnte sich immer noch unverhofft um vermutete 50% abdunkeln, weswegen ich ja besagte xorg.conf erzeugt hatte, die offensichtlich auf das Programm xbacklight zurückgreift. Der Befehl xbacklight -set 100 setzt die Bildschirmhelligkeit auf 100%.

Da die Bildschirmhelligkeit sich bisher nicht verringert hat und das neue stable Release (Bullseye) bald erscheinen wird, werde ich erst einmal nichts mehr an meinem Rechner in Bezug auf das hier berichtete Verhalten ändern. Vielleicht erübrigt sich das Problem (Xorg-Server friert ein bzw. Xorg-Server-Bildschirmhelligkeit verringert sich drastisch) ja fortwährend mit der Veröffentlichung von Bullseye.
peter1969 hat geschrieben: ↑ zum Beitrag ↑
23.06.2021 09:57:53
Eins hab ich nicht ganz verstanden: Benutzt Du bei Debian 10 den Modesetting-Treiber oder den Intel-Treiber? Bei einem meiner Laptops mit Intel-Grafik verursachte der Modesetting-Treiber auch unregelmäßige Abstürze. Der Intel-Treiber löste das Problem. So richtete ich ihn ein:

Erzeuge eine Datei /usr/share/X11/xorg.conf.d/80-mychanges.conf mit folgendem Inhalt:

Section "Device"
Identifier "Intel"
Driver "intel"
Option "TearFree" "true"
EndSection

Dann starte neu und überprüfe den Erfolg mit folgendem Befehl: # sudo grep -e intel /var/log/Xorg.0.log
Wenn der Intel-Treiber benutzt wird, müssen diverse Intel-Einträge erscheinen
Danke, Peter. Im ersten Beitrag dieses Threads siehst Du den Inhalt meiner xorg.conf. Dort ist als Treiber "intel" angegeben, allerdings verwendete ich andere Treiberoptionen als Du.

Warum erzeugst Du eine /usr/share/X11/xorg.conf.d/80-mychanges.conf statt einer /etc/X11/xorg.conf? Ich kann mir den Pfad /etc/X11/xorg.conf besser merken.

Benutzeravatar
prox
Beiträge: 371
Registriert: 08.07.2019 18:50:34
Lizenz eigener Beiträge: GNU General Public License

Re: Debian 10.x: X-Server friert ein - Ursache nicht lokalisiert

Beitrag von prox » 25.06.2021 16:46:35

prox hat geschrieben: ↑ zum Beitrag ↑
01.06.2021 20:51:50
Update:

Habe letzten Freitag die xorg.old wieder umbenannt in xorg.conf in /etc/X11 (für den Inhalt der xorg.conf siehe der erste Beitrag in diesem Thread) und das Paket xbacklight installiert. Dieses Paket ist meiner Meinung nach dafür zuständig, dass die Anweisungen in der xorg.conf vom X-Server umgesetzt werden können.

Bis eben fror X nicht ein, dann aber schon. Habe nach dem Einfrieren und vor dem Reboot das Ergebnis des Programms dmesg in eine Datei umgeleitet. In dieser Datei fallen die folgenden letzten 5 von 7 Zeilen auf:

Code: Alles auswählen

[  707.615368] ath: regdomain 0x8114 dynamically updated by country element
[  707.655599] wlp3s0: Limiting TX power to 20 (20 - 0) dBm as advertised by e0:28:6d:81:53:b3
[ 3412.114690] perf: interrupt took too long (2516 > 2500), lowering kernel.perf_event_max_sample_rate to 79250
[ 4574.977618] perf: interrupt took too long (3156 > 3145), lowering kernel.perf_event_max_sample_rate to 63250
[ 6097.250000] perf: interrupt took too long (3965 > 3945), lowering kernel.perf_event_max_sample_rate to 50250
[ 8204.685202] perf: interrupt took too long (4962 > 4956), lowering kernel.perf_event_max_sample_rate to 40250
[ 9454.817253] perf: interrupt took too long (6203 > 6202), lowering kernel.perf_event_max_sample_rate to 32000
Kann aus den letzten 5 Zeilen geschlossen werden, dass die Ursache für das Verhalten der installierte Kernel ist? Mein Kernel ist der folgende:
root@punk:~# uname -a
Linux punk 4.19.0-16-amd64 #1 SMP Debian 4.19.181-1 (2021-03-19) x86_64 GNU/Linux
root@punk:~#
Nachtrag:

Die Meldung "perf: interrupt took too long (x > y), lowering kernel.perf_event_max_sample_rate to z" kann nicht das Einfrieren des Xorg-Servers beschreiben, denn ein paar Tage später (mit aktivierter xorg.conf) trat das Verhalten wieder auf, das ich mit dmesg -H > Datei protokollierte (die Option -H erzeugt Zeitstempel), die letzten Zeilen in der erzeugten Datei sind:

Code: Alles auswählen

[Jun 2 17:19] perf: interrupt took too long (3189 > 3162), lowering kernel.perf_event_max_sample_rate to 62500
[Jun 2 17:55] perf: interrupt took too long (3990 > 3986), lowering kernel.perf_event_max_sample_rate to 50000
[Jun 2 18:46] perf: interrupt took too long (5021 > 4987), lowering kernel.perf_event_max_sample_rate to 39750
[Jun 2 19:22] perf: interrupt took too long (6294 > 6276), lowering kernel.perf_event_max_sample_rate to 31750
Der Xorg-Server fror aber nach 20 Uhr ein.

Benutzeravatar
prox
Beiträge: 371
Registriert: 08.07.2019 18:50:34
Lizenz eigener Beiträge: GNU General Public License

Re: Debian 10.x: X-Server friert ein - Ursache nicht lokalisiert

Beitrag von prox » 25.06.2021 16:54:43

willy4711 hat geschrieben: ↑ zum Beitrag ↑
23.06.2021 11:17:14
Es scheint also mit dem Start eines (beliebigen) Programms und dem gleichzeitigen Umschalten (change_workspace) auf eine
andere Arbeitsfläche, (gesteuert von Devilspie) zusammenzuhängen.

Voraussetzung ist allerdings, das eine VM läuft. :twisted:
Devispie2 ist im Autostart.
Hi Willy,

auf meinem betroffenen Rechner ist a) keine VM installiert, b) verwende ich keine andere Arbeitsfläche als die 1. (Standard-) Arbeitsfläche, und c) tritt das Verhalten auf meinem Rechner nie direkt beim Start eines Programms auf, sondern erst nach einer gewissen Weile (Dauer unterschiedlich), nachdem ich ein Programm in der GUI gestartet habe.

Die Ursache für das Verhalten (Xorg-Server friert ein bzw. Bildschirmhelligkeit reduziert sich um ca. 50%) scheint meiner Meinung nach die Kombination von Intel-Hardware und dem Xorg-Server zu sein.

Wie gesagt, ich habe die /etc/X11/xorg.conf umbenannt (deaktiviert) vor ca. 2 Wochen, seitdem ist Xorg kein einziges Mal eingefroren, siehe die bisher heute von mir erstellten Beiträge in diesem Thread.

Antworten