Fwd: 15.2: X seit letztem Update unbenutzbar langsam
zweiter Versuch, beim ersten mal nicht angekommen... -------- Weitergeleitete Nachricht -------- Betreff: 15.2: X seit letztem Update unbenutzbar langsam Datum: Tue, 15 Sep 2020 15:21:12 +0200 Von: Martin Hofius <martin@hofius-online.com> An: opensuse-de@opensuse.org Hallo, seit dem letzten Update (heute, 15.9.2020) ist mein Notebook unbenutzbar langsam geworden. Laut Systemaktivität bzw. top verbraucht X ständig 12%, also ein voller Thread. Was ich schon versucht habe: - Beim Start den Standard-Kernel statt des von Tuxedo installierten Kernels 5.5.7-1-default ausgewählt (keine Änderung). Vor dem Update war X auf diesem Rechner mit dem Tuxedo-Kernel sogar recht flott. - Google (bzw. Duck) spuckt nichts zu diesem Problem aus - journalctl spuckt zwar jede Menge an Daten aus, aber nichts, was ich damit in Zusammenhang bringen würde. - Xorg.0.log sagt, dass das Modul Intel nicht existiert - das ist aber bei zwei anderen Rechnern (15.0 und 15.2) auch so, die laufen aber ohne Probleme - der einzig auffällige Unterschied in der Xorg.0.log: nach der Zeile systemd-logind fehlt die Zeile xfree86: Adding drm device (/dev/dri/card0). Ich habe nur keine Ahnung, wo das herkommt. Das System ist ein Core i7 mit integrierter Grafik - also nicht besonderes, läuft seit 2015 einwandfrei. In diesem bedauere ich, dass ich kein BTRFS genommen habe . aber bisher war ext4 problemlos und bei BTRFS könnte die root-Partition etwas klein sein, die muss sich eine ältere SSD mist WIn10 teilen... Ideen? -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On 2020/09/15 21:49:56 +0200, Martin Hofius wrote:
Hallo,
seit dem letzten Update (heute, 15.9.2020) ist mein Notebook unbenutzbar langsam geworden. Laut Systemaktivität bzw. top verbraucht X ständig 12%, also ein voller Thread.
Was ich schon versucht habe:
- Beim Start den Standard-Kernel statt des von Tuxedo installierten Kernels 5.5.7-1-default ausgewählt (keine Änderung). Vor dem Update war X auf diesem Rechner mit dem Tuxedo-Kernel sogar recht flott.
- Google (bzw. Duck) spuckt nichts zu diesem Problem aus
- journalctl spuckt zwar jede Menge an Daten aus, aber nichts, was ich damit in Zusammenhang bringen würde.
- Xorg.0.log sagt, dass das Modul Intel nicht existiert - das ist aber bei zwei anderen Rechnern (15.0 und 15.2) auch so, die laufen aber ohne Probleme
Also ich habe auch in Tuxedo Laptop hier. Meine Graphik ist eine Kombi von Nvidia und Intel-OnCPU Graphik (kein Optimus). Schau mal, ob alle Kernel Modules geladen sind. Dazu mal lspci -vvv | sed -rn '/VGA compatible/,/\tKernel modules:/p' aufrufen. Die Module für den X server sind unter /usr/lib64/xorg/modules/drivers/ zu finden, für Imntel sind das intel_drv.so modesetting_drv.so d.h. entweder oder. Erstes Module ist aus dem Paket xf86-video-intel und letztes aus xorg-x11-server.
- der einzig auffällige Unterschied in der Xorg.0.log: nach der Zeile systemd-logind fehlt die Zeile xfree86: Adding drm device (/dev/dri/card0). Ich habe nur keine Ahnung, wo das herkommt.
Kernel-Modul nicht geladen?
Das System ist ein Core i7 mit integrierter Grafik - also nicht besonderes, läuft seit 2015 einwandfrei. In diesem bedauere ich, dass ich kein BTRFS genommen habe . aber bisher war ext4 problemlos und bei BTRFS könnte die root-Partition etwas klein sein, die muss sich eine ältere SSD mist WIn10 teilen...
-- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr
Am 16.09.20 um 08:43 schrieb Dr. Werner Fink:
On 2020/09/15 21:49:56 +0200, Martin Hofius wrote:
Hallo,
seit dem letzten Update (heute, 15.9.2020) ist mein Notebook unbenutzbar langsam geworden. Laut Systemaktivität bzw. top verbraucht X ständig 12%, also ein voller Thread. ...
- Xorg.0.log sagt, dass das Modul Intel nicht existiert - das ist aber bei zwei anderen Rechnern (15.0 und 15.2) auch so, die laufen aber ohne Probleme Also ich habe auch in Tuxedo Laptop hier. Meine Graphik ist eine Kombi von Nvidia und Intel-OnCPU Graphik (kein Optimus).
Schau mal, ob alle Kernel Modules geladen sind. Dazu mal
lspci -vvv | sed -rn '/VGA compatible/,/\tKernel modules:/p'
lspci -vvv | sed -rn '/VGA compatible/,/\tKernel modules:/p' 00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06) (prog-if 00 [VGA controller]) Subsystem: CLEVO/KAPOK Computer Device 0655 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 11 Region 0: Memory at f7800000 (64-bit, non-prefetchable) [size=4M] Region 2: Memory at e0000000 (64-bit, prefetchable) [size=256M] Region 4: I/O ports at f000 [size=64] [virtual] Expansion ROM at 000c0000 [disabled] [size=128K] Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit- Address: 00000000 Data: 0000 Capabilities: [d0] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [a4] PCI Advanced Features AFCap: TP+ FLR+ AFCtrl: FLR- AFStatus: TP- Kernel modules: i915 pcilib: sysfs_read_vpd: read failed: Input/output error pcilib: sysfs_read_vpd: read failed: Input/output error
aufrufen. Die Module für den X server sind unter
/usr/lib64/xorg/modules/drivers/
zu finden, für Imntel sind das
intel_drv.so modesetting_drv.so
d.h. entweder oder. Erstes Module ist aus dem Paket xf86-video-intel und letztes aus xorg-x11-server.
da finde ich den letzteren, also modesetting_drv.so
- der einzig auffällige Unterschied in der Xorg.0.log: nach der Zeile systemd-logind fehlt die Zeile xfree86: Adding drm device (/dev/dri/card0). Ich habe nur keine Ahnung, wo das herkommt. Kernel-Modul nicht geladen?
sieht so aus? Die Frage ist nur, warum? -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On 2020/09/16 09:28:16 +0200, Martin Hofius wrote:
Am 16.09.20 um 08:43 schrieb Dr. Werner Fink:
On 2020/09/15 21:49:56 +0200, Martin Hofius wrote:
Hallo,
seit dem letzten Update (heute, 15.9.2020) ist mein Notebook unbenutzbar langsam geworden. Laut Systemaktivität bzw. top verbraucht X ständig 12%, also ein voller Thread. ...
- Xorg.0.log sagt, dass das Modul Intel nicht existiert - das ist aber bei zwei anderen Rechnern (15.0 und 15.2) auch so, die laufen aber ohne Probleme Also ich habe auch in Tuxedo Laptop hier. Meine Graphik ist eine Kombi von Nvidia und Intel-OnCPU Graphik (kein Optimus).
Schau mal, ob alle Kernel Modules geladen sind. Dazu mal
lspci -vvv | sed -rn '/VGA compatible/,/\tKernel modules:/p'
lspci -vvv | sed -rn '/VGA compatible/,/\tKernel modules:/p' 00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06) (prog-if 00 [VGA controller]) Subsystem: CLEVO/KAPOK Computer Device 0655 [...] AFStatus: TP- Kernel modules: i915 pcilib: sysfs_read_vpd: read failed: Input/output error pcilib: sysfs_read_vpd: read failed: Input/output error
aufrufen. Die Module für den X server sind unter
/usr/lib64/xorg/modules/drivers/
zu finden, für Imntel sind das
intel_drv.so modesetting_drv.so
d.h. entweder oder. Erstes Module ist aus dem Paket xf86-video-intel und letztes aus xorg-x11-server.
da finde ich den letzteren, also modesetting_drv.so
- der einzig auffällige Unterschied in der Xorg.0.log: nach der Zeile systemd-logind fehlt die Zeile xfree86: Adding drm device (/dev/dri/card0). Ich habe nur keine Ahnung, wo das herkommt. Kernel-Modul nicht geladen?
sieht so aus?
Die Frage ist nur, warum?
a) existiert nicht b) ist blacklisted c) kann nicht geladen werden Erstmal ein modinfo i915 falls da ``Module i915 not found`` steht, dann a) Dann mal ein grep -rs i915 /etc/modprobe.d/ /etc/modules-load.d/ /etc/modules.conf da sollte ncht stehen, vorallem nicht ``blacklist i915`` Dann bleibt noch bei einem frich gebooteten System dmesg -T | grep i915 um zu sehen, ob und wie geladen wird. Nicht zu vergessen, die Kernel-Kommandozeile grep -E 'GRUB_CMDLINE_LINUX_DEFAULT.*i915' /etc/default/grub ob und was zB für i915 gesetzt wird -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr
Am 16.09.20 um 10:14 schrieb Dr. Werner Fink:
On 2020/09/16 09:28:16 +0200, Martin Hofius wrote:
Am 16.09.20 um 08:43 schrieb Dr. Werner Fink:
On 2020/09/15 21:49:56 +0200, Martin Hofius wrote:
Hallo,
seit dem letzten Update (heute, 15.9.2020) ist mein Notebook unbenutzbar langsam geworden. Laut Systemaktivität bzw. top verbraucht X ständig 12%, also ein voller Thread. ...
... Kernel-Modul nicht geladen?
sieht so aus?
Die Frage ist nur, warum?
a) existiert nicht b) ist blacklisted c) kann nicht geladen werden
Erstmal ein
modinfo i915
falls da ``Module i915 not found`` steht, dann a) nein, da gibt es längere Auflistung von Firmwaremodulen, PCI-Aliasnamen und Parametern - scheint mir gut auszusehen
Dann mal ein
grep -rs i915 /etc/modprobe.d/ /etc/modules-load.d/ /etc/modules.conf
Volltreffer: unter modprobe.d gab es da ein tuxedo-i915.conf mit 4 mal dem Eintrag options i915 enable_dcpd_backlight, was der Treiber wohl nicht mochte.
da sollte ncht stehen, vorallem nicht ``blacklist i915``
Dann bleibt noch bei einem frich gebooteten System
dmesg -T | grep i915
um zu sehen, ob und wie geladen wird.
und da tauchte dann die Beschwerde über die o.a. options auf.
Nicht zu vergessen, die Kernel-Kommandozeile
grep -E 'GRUB_CMDLINE_LINUX_DEFAULT.*i915' /etc/default/grub
ob und was zB für i915 gesetzt wird
nichts
Danke für die Tipps - das mit diesen options war es wohl, habe die Datei weggeschoben, jetzt läuft wieder alles wie gewohnt. Was mich nur wundert: die müssen da eigentlich schon seit 2 Monaten drin gewesen sein. Ich hatte das System mit 15.2 komplett neu aufgesetzt und dann das tuxedo.sh Script drüber laufen lassen. Das hat dann u.a. den Kernel gegen den neueren getauscht und dafür gesorgt, dass die Frequenzsteuerung der CPU wieder funktioniert. Dabei muss ja auch diese Modul-Konfigurationsdatei entstanden sein. Warum also das erst mit dem gestrigen Update gestört hat? Trotzdem vielen Dank für die Hilfe! Gruß Martin
participants (2)
-
Dr. Werner Fink -
Martin Hofius