Konntest Du etwas in den logs erkennen?
[yavdr-ansible] Standby
-
-
Ich denke ich werde den Standby erstmal abschalten. Booten dauert sowieso nicht so lange.
Evt. bin ich ja aber auch nicht allein mit diesem Problem, dann kann ich ja den Standby nochmal einschalten.
-
Habe gerade mein Testsystem über yavdr-ansible geupdated.
Anschließend Zeile hinzugefügt. Neu gestartet. Suspend aktiviert. Neustart nach ca. 6-8s.
Super Ding. Vielen Dank.
Eine Anfängerfrage habe ich noch:
Ist es nicht möglich die Zeile direkt mit poweroff hinzuzufügen, so dass man anschließend zwischen zB suspend und poweroff nur noch wechseln brauch?
War etwas irritiert, dass die Zeile gänzlich gefehlt hat.
Gruß
-
Ist es nicht möglich die Zeile direkt mit poweroff hinzuzufügen, so dass man anschließend zwischen zB suspend und poweroff nur noch wechseln brauch?
Ja, kann ich bei Gelegenheit noch machen (wobei das eventuell im Ansible-Playbook besser aufgehoben ist als im VDR-Paket) - wir hatten die /etc/default/vdr an damals aus dem Debian-Paket für den VDR übernommen: https://salsa.debian.org/vdr-t…master/debian/vdr.default
-
Ist es nicht möglich die Zeile direkt mit poweroff hinzuzufügen, so dass man anschließend zwischen zB suspend und poweroff nur noch wechseln brauch?
Das habe ich mittlerweile eingebaut - über die Variable vdr_shutdown_command kann man festlegen, was als SHUTDOWNCMD in der /etc/default/vdr gesetzt wird.
-
Ich habe auf Anregung von urknall noch ein paar Verbesserungen am Standby-Verhalten eingebaut: https://github.com/yavdr/yavdr…tes/system-sleep_yavdr.j2
- beim yavdr-frontend Skript wird die Statusmaschine für Shutdown-Versuche und das Attachen des VDR-Frontends zurückgesetzt (so dass z.B. ein Start für Timer berücksichtigt werden kann, bei dem das Frontend detached bleibt) - damit das funktioniert, braucht man die aktuelle Version von python3-yavdrfrontend aus dem experimental-main PPA.
- beim Resume wird darauf gewartet, dass das Netzwerk wieder bereit ist, damit sollten Plugins wie satip, epg2vdr usw. keine Probleme haben die jeweiligen Server zu kontaktieren
- Vor den standby werden die Avahi-Announcements für NFS-Freigaben deaktiviert und beim Resume wieder reaktiviert
-
Ich habe gerade in meinen lokalen host_vars die Shutdownmethode umgestellt (wie im ersten Posting angegeben) und dann das install-Skript nochmal laufen lassen und den PC neu gestartet.
Das Ausschalten (jetzt Standby) geht jetzt gefühlt etwas schneller.
Nach dem Einschalten kommt sofort das yavdr-Logo (statt bisher Bootscreen und Bootmeldungen) und nach einigen Sekunden verschwindet es, aber der Bildschirm bleibt schwarz.
Ich werde wohl morgen mal deine neueste GIT-Version holen und das install-Skript nochmal laufen lassen.
-
und nach einigen Sekunden verschwindet es, aber der Bildschirm bleibt schwarz.
Das dürfte der Zeitpunkt sein, zu dem das VDR-Frontend wieder attached wird. Kannst du mal das ungekürzte Syslog ab dem Zeitpunkt zu dem du die Power-Taste drückst bis zu dem Zeitpunkt, an dem der Rechner wieder aufgewacht ist (und kein Bild liefert) anhängen?
journalctl -l --since=-5m > log.txt schreibt dir z.B. die Logeinträge der letzten 5 Minuten in eine Datei.
-
Ach ja - zeig bitte auch mal die Ausgabe von journalctl -b -l -u systemd-suspend.service nach dem Resume, eventuell klappt das Entladen der DVB-Treibermodule nicht.
-
Ich habe die beiden Ausgaben als "log1" (ab Ausschalten) bzw. "log2" (nach resume) angehängt.
Beim Resumen sieht man, dass offenbar mein dvb-Treiber nicht geladen werden kann???
Da fehlt mir wohl die Geschichte mit "waiting for dvb device", oder?
-
Da scheint es einen Kernel-Oops beim Entladen der DVB-Treiber zu geben:
Code
Display MoreJun 22 13:26:31 myVDR kernel: WARNING: CPU: 1 PID: 4579 at /build/linux-Ue9GXV/linux-4.15.0/kernel/module.c:1141 module_put+0x8a/0xa0 Jun 22 13:26:31 myVDR kernel: Modules linked in: intel_rapl lnbp21 stb6100 ppdev stb0899 x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass intel_cstate intel_rapl_perf rc_tt_1500 budget_ci(-) budget_core ttpci_eeprom saa7146 dvb_core ftdi_sio input_leds usbserial snd_hda_codec_hdmi ir_rc6_decoder snd_hda_codec_realtek snd_hda_codec_generic rc_rc6_mce snd_hda_intel ir_lirc_codec lirc_dev snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer snd mei_me nuvoton_cir rc_core parport_pc parport soundcore mei shpchp lpc_ich nvidia_uvm(POE) mac_hid nfsd auth_rpcgss nfs_acl lockd grace sunrpc sch_fq_codel ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor Jun 22 13:26:31 myVDR kernel: async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear hid_generic usbhid hid nvidia_drm(POE) nvidia_modeset(POE) nvidia(POE) crct10dif_pclmul crc32_pclmul drm_kms_helper syscopyarea sysfillrect ghash_clmulni_intel sysimgblt cryptd fb_sys_fops ahci drm libahci atl1c ipmi_devintf ipmi_msghandler Jun 22 13:26:31 myVDR kernel: CPU: 1 PID: 4579 Comm: rmmod Tainted: P OE 4.15.0-51-generic #55-Ubuntu Jun 22 13:26:31 myVDR kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./H61M-GE, BIOS P1.30 08/31/2011 Jun 22 13:26:31 myVDR kernel: RIP: 0010:module_put+0x8a/0xa0 Jun 22 13:26:31 myVDR kernel: RSP: 0018:ffffaf2f015ebc48 EFLAGS: 00010297 Jun 22 13:26:31 myVDR kernel: RAX: ffffffffc18ab280 RBX: ffffffffc18a3190 RCX: 00000000ffffffff Jun 22 13:26:31 myVDR kernel: RDX: 0000000000000000 RSI: ffffffffc18a3000 RDI: ffffffffc18ab280 Jun 22 13:26:31 myVDR kernel: RBP: ffffaf2f015ebc60 R08: 0000000000000000 R09: 0000000000000282 Jun 22 13:26:31 myVDR kernel: R10: ffffffff99c06a80 R11: ffffaf2f015ebc00 R12: ffff8e5858ea8800 Jun 22 13:26:31 myVDR kernel: R13: ffffffffc18a3190 R14: ffff8e5853ff4d54 R15: ffff8e5853ff4c08 Jun 22 13:26:31 myVDR kernel: FS: 00007f800f379540(0000) GS:ffff8e585f500000(0000) knlGS:0000000000000000 Jun 22 13:26:31 myVDR kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jun 22 13:26:31 myVDR kernel: CR2: 000055f248ca4470 CR3: 00000000d1e92005 CR4: 00000000000606e0 Jun 22 13:26:31 myVDR kernel: Call Trace: Jun 22 13:26:31 myVDR kernel: ? _stb0899_read_reg+0x120/0x120 [stb0899] Jun 22 13:26:31 myVDR kernel: ? _stb0899_read_reg+0x120/0x120 [stb0899] Jun 22 13:26:31 myVDR kernel: symbol_put_addr+0x2e/0x40 Jun 22 13:26:31 myVDR kernel: __dvb_frontend_free+0x42/0x80 [dvb_core] Jun 22 13:26:31 myVDR kernel: ? stb0899_sleep+0x50/0x50 [stb0899] Jun 22 13:26:31 myVDR kernel: dvb_frontend_put+0x23/0x30 [dvb_core] Jun 22 13:26:31 myVDR kernel: dvb_frontend_detach+0x84/0x90 [dvb_core] Jun 22 13:26:31 myVDR kernel: budget_ci_detach+0xa5/0x1b0 [budget_ci] Jun 22 13:26:31 myVDR kernel: saa7146_remove_one+0xc3/0x210 [saa7146] Jun 22 13:26:31 myVDR kernel: pci_device_remove+0x3e/0xb0 Jun 22 13:26:31 myVDR kernel: ? saa7146_pgtable_alloc+0xf0/0xf0 [saa7146] Jun 22 13:26:31 myVDR kernel: ? pci_device_remove+0x3e/0xb0 Jun 22 13:26:31 myVDR kernel: device_release_driver_internal+0x15b/0x240 Jun 22 13:26:31 myVDR kernel: driver_detach+0x3f/0x80 Jun 22 13:26:31 myVDR kernel: bus_remove_driver+0x59/0xd0 Jun 22 13:26:31 myVDR kernel: driver_unregister+0x2c/0x40 Jun 22 13:26:31 myVDR kernel: pci_unregister_driver+0x22/0xa0 Jun 22 13:26:31 myVDR kernel: saa7146_unregister_extension+0x33/0x60 [saa7146] Jun 22 13:26:31 myVDR kernel: budget_ci_exit+0x10/0x8db [budget_ci] Jun 22 13:26:31 myVDR kernel: SyS_delete_module+0x1ab/0x2c0 Jun 22 13:26:31 myVDR kernel: do_syscall_64+0x73/0x130 Jun 22 13:26:31 myVDR kernel: entry_SYSCALL_64_after_hwframe+0x3d/0xa2 Jun 22 13:26:31 myVDR kernel: RIP: 0033:0x7f800ee931b7 Jun 22 13:26:31 myVDR kernel: RSP: 002b:00007ffe34b90b68 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 Jun 22 13:26:31 myVDR kernel: RAX: ffffffffffffffda RBX: 00007ffe34b90bc8 RCX: 00007f800ee931b7 Jun 22 13:26:31 myVDR kernel: RDX: 000000000000000a RSI: 0000000000000800 RDI: 00005601eeea17c8 Jun 22 13:26:31 myVDR kernel: RBP: 00005601eeea1760 R08: 00007ffe34b8fae1 R09: 0000000000000000 Jun 22 13:26:31 myVDR kernel: R10: 00007f800ef0fcc0 R11: 0000000000000206 R12: 00007ffe34b90d90 Jun 22 13:26:31 myVDR kernel: R13: 00007ffe34b91f1c R14: 00005601eeea1260 R15: 00005601eeea1760 Jun 22 13:26:31 myVDR kernel: Code: 04 24 48 89 fb 49 8b 7c 24 08 49 83 c4 18 4c 89 ea 48 89 de e8 48 f7 ad 00 49 8b 04 24 48 85 c0 75 e3 5b 41 5c 41 5d 5d c3 f3 c3 <0f> 0b eb a0 89 c2 eb 87 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 Jun 22 13:26:31 myVDR kernel: ---[ end trace 78a45a58f9ac4f34 ]--- Jun 22 13:26:31 myVDR systemd-sleep[4509]: rmmod: ERROR: Module budget_ci is not currently loaded
Und davon erholt sich das System wohl nicht mehr - ich fürchte, dass man mit der Hardware da nicht weiter kommt. Du könntest mal versuchen die Zeilen zum entladen und erneuten Laden der Treiber auszukommentieren, also https://github.com/yavdr/yavdr…system-sleep_yavdr.j2#L16 und https://github.com/yavdr/yavdr…system-sleep_yavdr.j2#L34 - vielleicht überlebt die Karte dann den Standby in einem funktionsfähigem Zustand.
-
Ich habe die beiden Zeilen direkt in der yavdr-Datei (/lib/systemd/system-sleep) auskommentiert und rebootet.
Und was soll ich sagen: es funktioniert!!!
seahawk1986 du bist einfach der Wahnsinn - vielen Dank!
Jetzt haben wir ca 10 Sekunden nach dem Einschalten Bild und Ton und alles scheint zu funktionieren - ein Traum!
Wir lieben yaVDR-ansible
Werde das noch templaten und das install-Skript dann nochmal laufen lassen ...
-
Hab den Standby jetzt auch getestetet (Hardware ist Cine S2 (ddbridge))
in
/yavdr-ansible/host_vars/localhost
folgendes eingefügt
branch: jammy
ppa_owner: 'ppa:seahawk1986-hotmail'
vdr_shutdown_command: "/bin/systemctl suspend"
Playbook laufen lassen
kein Bild,
auskommentieren s.o ging nicht
nach
/bin/systemctl stop vdr
/usr/local/bin/module-helper -u dvb_core
/usr/local/bin/module-helper -r
/bin/systemctl start vdr
war dann alles da
hab dann einfach
/lib/systemd/system-sleep/yavdr
wie folgt geändert:
echo "restore dvb drivers"
/usr/local/bin/module-helper -u dvb_core
/usr/local/bin/module-helper -r
sicher nicht elegant aber geht
Participate now!
Don’t have an account yet? Register yourself now and be a part of our community!