yaVDR wacht nach "Suspend to Ram" nicht mehr auf ...

Hallo!

Seit dem letzten Update vor ein paar Tagen, mag unser yaVDR nicht mehr aus dem Ruhezustand aufwachen.

Man sieht dann nur einen verpixelten schmalen Balken oben und drunter steht "CPU0 ..." und "CPU1 ...", ansonsten schwarzes Bild - siehe Foto im Anhang.

Egal wie lange ich warte, mehr passiert nicht. Nur ein beherzter Druck auf die Reset-Taste erweckt den VDR wieder zum Leben.

Im Syslog steht zwischen dem Beenden (suspend-to-ram) und dem neuerlichen Start nach Hardware-Reset-Taste einfach gar nichts; es gibt nur eine zeitliche Lücke:

May 28 18:28:03 myVDR vdr: [1241] caught signal 15
May 28 18:28:03 myVDR vdr: [1241] exiting, exit code 0
May 28 18:28:04 myVDR anacron[27387]: Anacron 2.3 started on 2018-05-28
May 28 18:28:04 myVDR anacron[27387]: Normal exit (0 jobs run)
May 28 18:28:05 myVDR kernel: [21328.800448] init: irexec main process (915) killed by TERM signal
May 28 18:28:05 myVDR kernel: [21328.966679] init: eventlircd main process (909) killed by TERM signal
May 28 18:28:05 myVDR kernel: [21329.086528] saa7146: unregister extension 'budget_ci dvb'
May 28 18:28:05 myVDR acpid: input device has been disconnected, fd 7
May 28 18:28:05 myVDR acpid: input device has been disconnected, fd 13

>>>> hier war dann das beschriebene Bild (siehe Anhang) bis ich manuell die Reset-Taste gedrückt habe <<<<

May 28 18:34:07 myVDR rsyslogd: [origin software="rsyslogd" swVersion="7.4.4" x-pid="1042" x-info="http://www.rsyslog.com"] start
May 28 18:34:07 myVDR rsyslogd-2307: warning: ~ action is deprecated, consider using the 'stop' statement instead [try http://www.rsyslog.com/e/2307 ]
May 28 18:34:07 myVDR rsyslogd: rsyslogd's groupid changed to 104

Hat jemand eine Idee, wie ich den Ruhezustand wieder zum Laufen bekomme?

Braucht ihr noch weitere Log-Auszüge? Wenn ja: früher oder später?

Vielen Dank schon jetzt für eure Hilfe!

Hier der gewünschte Auszug kurz vor dem shutdown bis zum Einfrieren. Ich kann da leider nichts Auffälliges entdecken.

Ich hatte im webif mehrmals die Abschaltmethode umgestellt und am Ende wieder zurück auf "suspend to ram" - daher die "debug: parsing"-Einträge.

https://pastebin.com/NZh6Ds4B

Danke für deine Unterstützung!

Habe jetzt beim Ausschalten ein mal einen segfault im syslog gehabt:

May 30 22:02:14 myVDR kernel: [117681.249247] device 1 TS buf[31485]: segfault at a ip 00007f788fbf07d9 sp 00007f77ffaae9c0 error 4 in libc-2.19.so[7f788fb72000+1be000]6-07]Kann das mit dem Nicht-mehr-aufwachen zusammenhängen?

Habe erst jetzt festgestellt, dass offenbar seit 27.03.2018 keine Änderung der/var/cache/vdr/acpiwakeup.time.old mehr erfolgt ist:

Jun  2 19:25:27 myVDR vdr-frontend[2048]: acip-wakeup.time.old hatte Wert: Tue Mar 27 18:08:00 2018
Jun  2 19:25:27 myVDR vdr-frontend[2048]: vergleiche mit jetzt: Sat Jun  2 17:25:27 2018

Heißt das, dass suspend-to-ram damals das letzte Mal erfolgreich gelaufen ist?

Die Datei gehört übrigens dem User vdr und kann von ihm geändert werden: -rw-r--r-- 1 vdr vdr 20 Apr 9 13:44 acpiwakeup.time.old

Ich bin jetzt nach Anleitung "DebuggingKernelSuspend" vorgegangen und kann jetzt tatsächlich im Output von dmesg eine "Magic number" mit "hash matches" finden:

[    0.658856]   Magic number: 6:813:227
[    0.658899] acpi PNP0200:00: hash matches
[    0.658954] rtc_cmos 00:05: setting system clock to 2018-06-05 12:12:51 UTC (1528200771)

lspci liefert leider nichts, was ich damit in Verbindung bringen würde:

00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core Processor Family PCI Express Root Port (rev 09)
00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 05)
00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 05)
00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b5)
00:1c.1 PCI bridge: Intel Corporation 82801 PCI Bridge (rev b5)
00:1c.2 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 3 (rev b5)
00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 05)
00:1f.0 ISA bridge: Intel Corporation H61 Express Chipset Family LPC Controller (rev 05)
00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family SATA AHCI Controller (rev 05)
00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 05)
01:00.0 VGA compatible controller: NVIDIA Corporation GF119 [GeForce GT 520] (rev a1)
01:00.1 Audio device: NVIDIA Corporation GF119 HDMI Audio Controller (rev a1)
03:00.0 PCI bridge: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI Bridge (rev 03)
04:00.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
04:01.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
05:00.0 Ethernet controller: Qualcomm Atheros AR8151 v2.0 Gigabit Ethernet (rev c0)

Das einzige Gerät "PNP0200" das ich finde ist der Ordner /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:01/PNP0200:00 mit folgendem Inhalt:

ls -l
insgesamt 0
-r--r--r-- 1 root root 4096 Jun  5 14:24 hid
-r--r--r-- 1 root root 4096 Jun  5 14:24 modalias
-r--r--r-- 1 root root 4096 Jun  5 14:24 path
lrwxrwxrwx 1 root root    0 Jun  5 14:24 physical_node -> ../../../../../pnp0/00:04
drwxr-xr-x 2 root root    0 Jun  5 14:19 power
lrwxrwxrwx 1 root root    0 Jun  5 14:24 subsystem -> ../../../../../../bus/acpi
-rw-r--r-- 1 root root 4096 Jun  5 14:12 uevent

Der Symlink vom "physical_node" zeigt auf /sys/devices/pnp0/00:04 mit folgendem Inhalt

ls -l
insgesamt 0
lrwxrwxrwx 1 root root    0 Jun  5 14:27 firmware_node -> ../../LNXSYSTM:00/device:00/PNP0A08:00/device:01/PNP0200:00
-r--r--r-- 1 root root 4096 Jun  5 14:13 id
-r--r--r-- 1 root root 4096 Jun  5 14:27 options
drwxr-xr-x 2 root root    0 Jun  5 14:19 power
-rw-r--r-- 1 root root 4096 Jun  5 14:27 resources
lrwxrwxrwx 1 root root    0 Jun  5 14:27 subsystem -> ../../../bus/pnp
-rw-r--r-- 1 root root 4096 Jun  5 14:12 uevent

Um welches Gerät handelt es sich jetzt konkret?

Und wie finde ich dann heraus, warum genau dieses nicht mehr aufwachen mag?

Danke für deine ausführliche Antwort!

Das wär aber dann ein grober Schnitzer, der sicherlich mehreren yaVDR-Nutzern aufgefallen wäre, oder?

Kernel müsste übrigens 3.13 sein. Hab da nie bewusst was gemacht, außer apt-get update & dist-upgrade.

Aber ich werds mal probieren, verzweifelt wie ich bin.

Update:

Bei mir wird hier auf Version 2.6.2 abgefragt und mein Kernel > 2.6.3 daher sollte ja eh „wakealarm“ verwendet werden, oder?

Update2:

Jetzt hab ichs geschnallt, sorry.

Update3:

Ausprobiert (Gte und Lte vertauscht) und jetzt kommt beim Ausschalten: „ACPI not installed - Shutdown abgebrochen“

Habe deinen Tipp mit WOL (aus anderem Thread) ausprobiert, aber mein yaVDR scheint überhaupt nicht auf WOL zu reagieren - habe ich wohl noch nie eingerichtet, weil nie gebraucht.

Wäre aber auch blöd, wenn ich den yaVDR nach dem Einschlafen (suspend-to-ram) nur mehr per WOL wecken könnte - WAF!

Wenn es stimmt, dass S3 seit 27.3.18 nicht mehr funktioniert (siehe #5), dann tippe auf ein Kernelupdate; der Nvidia-Treiber (384) wurde nämlich erst kürzlich aktualisiert, als S3 schon nicht mehr funktionierte.

Hat niemand eine Idee woran suspend-to-ram (plötzlich) scheitert?

Habe jetzt sogar Die Kernel-Boot-Option „reboot“ mit allen möglichen Einstellungen (bios,acpi,...) ausprobiert, aber der PC friert beim Aufwachen sofort ein. ☹️

Hab leider im Bios nichts zu WOL finden können.

Die LED von LAN-Anschluß leuchtet bei ausgeschaltetem PC.

Danke, Ole, für deine Antworten!

Jetzt wo du es sagst: ich hatte das schon mal benötigt, war dann aber nicht mehr notwendig - siehe Thread.

"Damals" stand "dvb-core" in der Datei, werde ich gleich mal ausprobieren ...

Habs jetzt mit „dvbcore“ und „nvidia“ bzw beidem probiert - keine Änderung.

Ich glaube auch nicht, dass es damit zu tun hat, weil das Einfrieren viel zu schnell passiert.

Das Freeze-Bild (siehe oben) kommt fast unmittelbar (< 1 s) nach dem Einschalten.

Noch jemand einen Tipp? biiiiiiitttte ?

Update:

Habe gelesen, dass mancheiner (Lars *zwinker*) wohl yaVDR mit S5 betreibt.

S4 (od S5) wäre mir ja sogar noch lieber, aber ich fürchte, dass dafür erstmal S3 sauber laufen muss.

Bin jetzt sogar zurück auf den nvidia Treiber 304(.135) und habe bei „reload-modules“ „nvidia“ u „dvb-core“ eingetragen.

Immerhin steht jetzt beim Ausschalten am Schluss was von „suspend mem“ im syslog. Aber beim Auswachen friert er wieder ein ?

(Btw: WOL funzt jetzt. Danke Ole, es war die „PCI“-Option)

Habe mal kurz mit yaVDR 0.5 getestet (Dualboot) u dort klappt das Aufwachen aus S3 problemlos u ohne reload modules/services????

Hmmmm ... danke für den Hinweis! Das habe ich offenbar übersehen. Schaut bei mir (dmesg) ganz anders aus.

Das einzige USB-Gerät, das bewusst angesteckt ist, benötige ich um Sender hell zu kriegen.

Aber natürlich werde ich ausprobieren, ob der S3 ohne USB-Gerät dann funktioniert.

Update:

Hatte neben dem Kartenleser auch noch eine USB-Tastatur dran. Habe beides abgezogen und einen Reboot durchgeführt.

Dann den VDR ca 5 Minuten laufen lassen und dann in S3 versetzt. Dann ca. 2 Minuten gewartet und aufgeweckt. Aber friert er leider sofort wieder ein.

Daran liegts also auch nicht.