Arch Linux

Bildschirm wird nicht aus dem Ruhezustand aufgeweckt (Gnome3)

oIIIIIIIo

Hallo miteinander,

seit irgendeinem Update (vor ein paar Monaten) wird das Display von meinem Notebook unter Gnome 3 nicht mehr aufgeweckt.
Der Ruhezustand selbst wird vermutlich der Festplattenaktivität nach aufgehoben. Ich muss jedesmal den Rechner komplett ausschalten und neu booten.
Weiß von euch einer Rat wo bzw. wie ich den Fehler finden kann?

Danke fürs drüberschauen
Grüße Chris!

Das sind meine Configs bzw. die aktiven systemd-Dienste:

Auszug aus /boot/grub/grub.cfg:

linux	/boot/vmlinuz-linux root=UUID=60ee440f-8631-4a9a-8f5e-19d98a1fdbf7 resume=/dev/sda5 rw

(/dev/sda5 ist meine Swap-Partition)

Auszug aus /etc/mkinitcpio.conf:

HOOKS="base udev autodetect modconf block filesystems keyboard fsck resume"

/etc/systemd/system/suspend@.service

[Unit]
Description=User suspend actions
Before=sleep.target

[Service]
User=%I
Type=simple
Environment=DISPLAY=:0
ExecStartPre= -/usr/bin/pkill -u %u unison ; /usr/local/bin/music.sh stop ; /usr/bin/mysql -e 'slave stop'
ExecStart=/usr/bin/sflock
ExecStartPost=/usr/bin/sleep 1

[Install]
WantedBy=sleep.target

/etc/systemd/system/resume@.service

[Unit]
Description=User resume actions
After=suspend.target

[Service]
User=%I
Type=simple
ExecStartPre=/usr/local/bin/ssh-connect.sh
ExecStart=/usr/bin/mysql -e 'slave start'

[Install]
WantedBy=suspend.target

/etc/systemd/system/root-resume.service

[Unit]
Description=Local system resume actions
After=suspend.target

[Service]
Type=simple
ExecStart=/usr/bin/systemctl restart mnt-media.automount

[Install]
WantedBy=suspend.target

/etc/systemd/system/root-suspend.service

[Unit]
Description=Local system suspend actions
Before=sleep.target

[Service]
Type=simple
ExecStart=-/usr/bin/pkill sshfs

[Install]
WantedBy=sleep.target

Werner

oIIIIIIIo schrieb… seit irgendeinem Update (vor ein paar Monaten) wird das Display von meinem Notebook unter Gnome 3 nicht mehr aufgeweckt.
Der Ruhezustand selbst wird vermutlich der Festplattenaktivität nach aufgehoben. Ich muss jedesmal den Rechner komplett ausschalten und neu booten.

Wenn ich dich richtig verstehe, wird der Rechner zwar wach, aber der Bildschirm bleibt schwarz.

Dieses Problem habe ich seit einiger Zeit bei meinem ThinkPad mit xfce4 und der Bildschirm-Energieverwaltung.
Damit der Bildschirm wieder erwacht, muss ich zuerst via Strg+Alt in ein anderes TTY wechseln und dann in‘s TTY 7, in dem der XServer läuft. Funktioniert dieser Umweg auch bei dir? Das ist zwar keine Lösung, aber immerhin besser als ein Neustart.

Die Ursache dafür habe ich bislang noch nicht finden können; die Logs geben leider auch nichts her, was zielführend wäre.

Gruß, Werner

Edit: Ups, da hatte ich doch tatsächlich ein Deppenapostroph im Text eingebaut; schnell noch redigiert, bevor es jemand merkt. 🙂

oIIIIIIIo

Werner schrieb ...Damit der Bildschirm wieder erwacht, muss ich zuerst via Strg+Alt in ein anderes TTY wechseln und dann in‘s TTY, in dem der XServer läuft...

Vielen Dank für den Tipp, Werner!
Das mit dem Konsolenwechsel hat funktioniert! Auf die Idee bin ich noch gar nicht gekommen. Das ist zumindest schon einmal eine gangbare Übergangslösung.
Mit den Logs bin ich auch nicht weiter gekommen, zumindest habe ich nichts gefunden, was mir weiter hilft.

Gruß Chris

[gelöscht]

Das englische Wiki hält ein paar Hinweise parat –>
wiki.archlinux.org/index.php/Hibernate#Suspend/hibernate doesn't work, or not consistently

Als Workaround wird einmal empfohlen, auf den LTS-Kernel auszuweichen, oder aber evtl. vorhandene Grafik-Module aus dem initramfs (sonst für early KMS verwendet) zu entfernen.

Ich habe das Problem allerdings nicht, weder auf dem Laptop mit nouveau im initramfs und rootless X auf tty1, noch auf dem Desktop mit LTS-Kernel, nvidia-304xx sowie X auf tty7 (beide Geräte Intel Core 2 Duo mit xfce4).

Werner

Da die Sache keine große Beeinträchtigung ist, möchte ich nicht gerne auf den LTS-Kernel ausweichen. Im initramfs ist bei mir kein Grafikmodul eingetragen. Schade, ich fand deinen Hinweis plausibel.

k.osmoff schrieb… Ich habe das Problem allerdings nicht, …

Ich habe 2 Arch-Notebooks, ein in die Jahre gekommenes Sony Z11 (Core2) und ein Thinkpad, beide xfce4 und Intelgrafik. Das Problem tritt bei mir nur mit dem Thinkpad auf.
Ob das evtl. mit dem spezifischen Thinkpad-ACPI zusammenhängt? Ich weiß es nicht.

$ lsmod | grep think
thinkpad_acpi          77824  1
nvram                  16384  1 thinkpad_acpi
snd                    65536  16 snd_hda_codec_realtek,snd_hwdep,snd_timer,snd_pcm,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel,thinkpad_acpi
rfkill                 20480  7 cfg80211,thinkpad_acpi,bluetooth
video                  36864  2 i915,thinkpad_acpi
led_class              16384  4 sdhci,iwldvm,thinkpad_acpi,input_leds

@chris
Tritt das Problem bei dir auch auf einem Thinkpad auf?

Gruß, Werner

oIIIIIIIo

Werner schrieb
...@chris
Tritt das Problem bei dir auch auf einem Thinkpad auf?...

Nein, ich habe ein ASUS X5DIJ mit Intel-Grafikchipsatz (Intel GMA 4500M).

$lspci -vvv
...

00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller])
	Subsystem: ASUSTeK Computer Inc. Device 1862
	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 30
	Region 0: Memory at fd800000 (64-bit, non-prefetchable) [size=4M]
	Region 2: Memory at d0000000 (64-bit, prefetchable) [size=256M]
	Region 4: I/O ports at cc00 [size=8]
	[virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
	Capabilities: <access denied>
	Kernel driver in use: i915
	Kernel modules: i915

00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 09)
	Subsystem: ASUSTeK Computer Inc. Device 1862
	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
	Region 0: Memory at fdd00000 (64-bit, non-prefetchable) [size=1M]
	Capabilities: <access denied>

...

$ sudo lspci -vvv
...

00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller])
	Subsystem: ASUSTeK Computer Inc. Device 1862
	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 30
	Region 0: Memory at fd800000 (64-bit, non-prefetchable) [size=4M]
	Region 2: Memory at d0000000 (64-bit, prefetchable) [size=256M]
	Region 4: I/O ports at cc00 [size=8]
	[virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
	Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
		Address: fee0300c  Data: 41d2
	Capabilities: [d0] Power Management version 3
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: i915
	Kernel modules: i915

00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 09)
	Subsystem: ASUSTeK Computer Inc. Device 1862
	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
	Region 0: Memory at fdd00000 (64-bit, non-prefetchable) [size=1M]
	Capabilities: [d0] Power Management version 3
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
...

$ dmesg | grep -i intel  

[    0.000000] Reserving Intel graphics stolen memory at 0xbe000000-0xbfffffff
[    0.076666] smpboot: CPU0: Intel Pentium(R) Dual-Core CPU       T4200  @ 2.00GHz (family: 0x6, model: 0x17, stepping: 0xa)
[    0.076666] Performance Events: PEBS fmt0+, 4-deep LBR, Core2 events, Intel PMU driver.
[    0.810064] intel_idle: does not run on family 6 model 23
[   13.264708] pci 0000:00:00.0: Intel GM45 Chipset
[   13.265085] fb: switching to inteldrmfb from VESA VGA
[   13.775484] input: HDA Intel Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input15
[   13.775584] input: HDA Intel Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input16
[   13.879530] fbcon: inteldrmfb (fb0) is primary device
[   15.080134] intel_powerclamp: No package C-state available
[   15.083608] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[   15.094176] intel_powerclamp: No package C-state available
[   15.366618] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11

$ sudo lspci -vnn
...

00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 09) (prog-if 00 [VGA controller])
	Subsystem: ASUSTeK Computer Inc. Device [1043:1862]
	Flags: bus master, fast devsel, latency 0, IRQ 30
	Memory at fd800000 (64-bit, non-prefetchable) [size=4M]
	Memory at d0000000 (64-bit, prefetchable) [size=256M]
	I/O ports at cc00 [size=8]
	[virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
	Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
	Capabilities: [d0] Power Management version 3
	Kernel driver in use: i915
	Kernel modules: i915

00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a43] (rev 09)
	Subsystem: ASUSTeK Computer Inc. Device [1043:1862]
	Flags: bus master, fast devsel, latency 0
	Memory at fdd00000 (64-bit, non-prefetchable) [size=1M]
	Capabilities: [d0] Power Management version 3

[gelöscht]

Ich hab' gerade mal den im Wiki verlinkten Artikel zu den "best practices" beim Debuggen von suspend/hibernate-Problemen durchgesehen. Darin heißt es unter Punkt 3.1, ein typischer Fehler sei eine "Regression", d. h. ein Kernel-Update, das mit einer Änderung diesen Fehler eingeführt hat. Leider scheint es in eurer Situation nicht ganz nachvollziehbar, seit welchem Update das Problem auftritt, sonst könnten wir da ansetzen und nach dem entsprechenden commit fahnden. Ansonsten empfehle ich noch den Punkt 3.2.1 Graphics issue anzusehen, da ist nämlich speziell die Rede von Intel. Typischerweise sollte sich das im Kernel-Log niederschlagen, wie ein Auszug auf der Seite zeigt.

https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/hibernate-issues

Eine Lösung gibt es da nicht, nur die Empfehlung, einen Bugreport auf bugs.freedesktop.org abzusetzen. Ich vermute jedenfalls, es liegt an der Intel-Grafik, wie @chris auch zeigt.

[gelöscht]

Bug-Report vom 4. Januar 2016 –> https://bugs.freedesktop.org/show_bug.cgi?id=93574

oIIIIIIIo

@k.osmoff

Erstmal Danke! Scheint wohl ein Problem mit dem i915 Kernelmodul zu sein.

Gruß Chris

Photor

oIIIIIIIo schrieb@k.osmoff

Erstmal Danke! Scheint wohl ein Problem mit dem i915 Kernelmodul zu sein.

Gruß Chris

Hallo Chris,

da hat gerade was bei mir im Kopf geklingelt: mir ist so, als ob ich das Problem auch schon mal hatte. Probier doch mal ein paar Einstellungen in der xorg.conf. Hier die /etc/X11/xorg.conf.d/20-intel.conf von meinem Thinkpad T440s:

Section "Device"
        Identifier      "card0"
        Driver  "intel"
#       Option  "AccelMethod"   "uxa"   # nicht einkommentieren, Problem bei 
#                                       # wieder aufwachen
        Option  "TearFree"      "true"  # TEST um "Flackern" zu beseitigen
        Option  "DRI"   "3"
        Option  "Backlight"     "intel_backlight"
        BusID   "PCI:0:2:0"
EndSection

Sowohl die "Backlight"-Option als auch "DRI" könnte einen Versuch wert sein. Und beachte den Kommentar zu "AccelMethod". Viel Glück

ciao,

Photor

PS: alles auf eigene Gefahr, versteht sich

Werner

@Photor, @chris
Ich habe es gerade auf diesem Weg lösen können, allerdings klappte das bei mir in /etc/X11/xorg.conf.d/20-intel.conf nicht.
Zunächst habe die BusID ausgelesen …

lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)

… und dann die Datei /usr/share/X11/xorg.conf.d/20-intel.conf angelegt:

Section "Device"
        Identifier      "Intel Graphics"
        Driver          "intel"
        Option          "Backlight" "intel_backlight"
        BusID           "PCI:0:2:0"
EndSection

Nach einmal ab- und wieder anmelden läuft‘s nun wieder wie es soll.

Gruß, Werner

Edit:

@Photor
Danke für deinen Hinweis!

oIIIIIIIo

Werner schrieb … und dann die Datei /usr/share/X11/xorg.conf.d/20-intel.conf angelegt:
Section "Device"
        Identifier      "Intel Graphics"
        Driver          "intel"
        Option          "Backlight" "intel_backlight"
        BusID           "PCI:0:2:0"
EndSection
Nach einmal ab- und wieder anmelden läuft‘s nun wieder wie es soll.
...

Mit der "/etc/X11/xorg.conf.d/20-intel.conf" hatte ich auch schon einmal erfolglos herumexperimentiert.

Aber die obige "usr/share/X11/xorg.conf.d/20-intel.conf" war die Lösung! 🙂 😃 🙂

Vielen Dank
an Werner, Photor und k.osmoff für das Erarbeiten der Lösung!

Grüße Chris

[gelöscht]

Hmm, also so richtig verstehe ich es nicht, weshalb für Photor das Verzeichnis /etc/X11/xorg.conf.d/ hinreichend ist, während es für Chris und Werner das Verzeichnis /usr/share/X11/xorg.conf.d/ sein muss. Gibt es da so weitreichende Unterschiede in der jeweiligen Prozessorarchitektur resp. dem IGP, während ihr alle denselben Treiber nutzt?

oIIIIIIIo

@k.osmoff

Ich habe es gerade extra nochmal ausprobiert.
Die Konfigurationsdatei 20-intel.conf funktioniert bei mir definitiv nur unter "usr/share/X11/xorg.conf.d/" und nicht unter "/etc/X11/xorg.conf.d/".

???

Werner

Xorg beschreibt es so:
»Finally, configuration files will also be searched for in directories reserved for system use. These are to separate configuration files from the vendor or 3rd party packages from those of local administration. These files are found in the following directories:
/usr/share/X11/xorg.conf.d«

Die Mitteilung der BusID für‘s Backlight ist ja keine Konfiguration im eigentlichen Sinne, sondern eine informelle systemweite (herstellerspezifische) Angelegenheit. So verstehe ich das jedenfalls.

Gruß, Werner

[gelöscht]

@Werner: Naja, das Verzeichnis /etc ist ja für lokale, systemweite Konfiguration (diese eine Maschine) gedacht, während in /usr alle möglichen Maschinen (mit derselben Architektur) gemeint sind, um Interoperabilität und Portabilität zu ermöglichen. Zur Veranschaulichung der Inhalt von /usr/share/X11/xorg.conf.d/ auf meinen oben genannten zwei Maschinen –>

[k.osmo@nvidia-Desktop ~]$ ls /usr/share/X11/xorg.conf.d/
10-evdev.conf  10-quirks.conf  nvidia-drm-outputclass.conf
[k.osmo@nouveau-Laptop ~]$ ls /usr/share/X11/xorg.conf.d/
10-evdev.conf  10-quirks.conf  70-synaptics.conf

Die Argumentation, dass das "herstellerspezifisch" sei, kann ich zwar nachvollziehen, allerdings sollten Veränderungen in /usr nur durch Treiber-(De-)Installation und nicht manuell erfolgen (müssen), sagt man 7 file-hierarchy:

/usr
Vendor-supplied operating system resources. Usually read-only,
but this is not required. Possibly shared between multiple hosts.
This directory should not be modified by the administrator,
except when installing or removing vendor-supplied packages.

Weshalb lässt sich bei dir und Chris die Bus-ID lokal, systemweit nicht über das eigentlich dafür vorgesehene Verzeichnis /etc bekanntmachen, bei Photor aber schon?