Neues X server Handling in der runvdr-extreme. Bitte um Tester.

M-Reimer · 7. Januar 2014

Ein VDR-Absturz sollte auch in der alten Version zu einem Neustart des X-Servers führen. Es gab Zeiten wo das auch durchaus angebracht war, weil der Nvidia-Treiber durchaus für Probleme sorgen konnte. Keine Ahnung ob man heutzutagen den X-Server durchlaufen lassen könnte.

Bleibt die Frage, warum der VDR überhaupt abstürzt. Ist aber nicht das erste Problem beim Suspenden. Hast du die neueste GIT-Version vom softhddevice installiert?

dad401 · 12. Januar 2014

Ich habe bisher die V0.6.0 von softhddevice, aber auch das aktuelle git von heute bringt den Absturz:

Code

Jan 12 13:31:02 macvdr kernel: [10360.753153] vdr[5437]: segfault at b174017b ip b174017b sp 941ff230 error 14 in libnss_compat-2.13.so[b1e25000+6000]

Ich nutze den NVIDIA-Treiber (Version: 304.88-1+deb7u1) von Debian.

Ein Backtrace liefert leider nicht viel:

Code

GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/local/bin/vdr...done.
[New LWP 5437]
[New LWP 5398]


warning: Can't read pathname for load map: Eingabe-/Ausgabefehler.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1".
Core was generated by `/usr/local/bin/vdr 1> /var/log/vdr/runvdr.log 2>&1 -c /etc/vdr-1.7.26 -g /ramdi'.
Program terminated with signal 11, Segmentation fault.
#0  0xb174017b in ?? ()
(gdb) bt
#0  0xb174017b in ?? ()
#1  0x08430050 in ?? ()
Cannot access memory at address 0xb7405204

Alles anzeigen

Ist ggf. ggü. der alten runvdr-Version noch etwas am Aufruf zu ändern - derzeit sieht das in meinem init.d Skript so aus:

Code

LOGFILE="/var/log/vdr/runvdr.log"
DAEMON=/usr/local/bin/runvdr  # das ist das Skript
DAEMONARGS="-C /etc/runvdr-$VDRVERSION-initd.conf 1> $LOGFILE 2>&1"
PIDFILE=/var/run/runvdr.pid


#   Function that starts runvdr.
#
d_start() {
	log_daemon_msg "Starting runvdr extreme : $NAME"
	start-stop-daemon --start --background --quiet --pidfile $PIDFILE \
    	--exec $DAEMON -- $DAEMONARGS
	log_end_msg $?
}

Alles anzeigen

Marcus

M-Reimer · 12. Januar 2014

Irgendwer produziert einen Segfault. Deaktiviere mal alle VDR-Plugins, die du nicht unbedingt brauchst. Soll heißen: Wenn irgendwie möglich, dann alles außer softhddevice weg! Hänge auch mal deine runvdr.conf an.

dad401 · 12. Januar 2014

Ich habe nun alle Plugins außer SHDD entfernt. Dasselbe Problem, jedoch ohne Segfault. Der VDR startet einfach neu nachdem ich SHDD ein "SUSP" gebe - mit der runvdr 0.5.0 klappt alles - da kann ich SHDD wieder ein RESU schicken und das Bild ist wieder da.

Ich habe sogar den NVIDIA-Treiber von Debian entfernt und einen anderen direkt installiert. Selbes Problem. Nebenbei wollte ich auch den aktuellen 331.20 Treiber installieren - bei diesem friert der Rechner beim Start des VDR völlig ein (hat jetzt nichts mit der runvdr zu tun - ist bei beiden Versionen so).

Dessweiteren habe ich

Code

DAEMONARGS="-C /etc/runvdr-$VDRVERSION-initd.conf 1> $LOGFILE 2>&1"

in

Code

DAEMONARGS="-C /etc/runvdr-$VDRVERSION-initd.conf"

geändert.

Alles ohne Erfolg.

Hier mal die Konfiguratiosdateien.

Marcus

M-Reimer · 13. Januar 2014

Das muss ich bei mir mal durchspielen, was passiert, wenn ich "SUSP" auslöse. Irgendwo muss sich softhddevice ja was anders verhalten als beim mit xinit gestarteten X-Server. Notfalls baue ich an den passenden Stellen mal nen Schwung printfs hin.

Was wohl passiert, ist, dass die letzte Verbindung zum Server geschlossen wird. Dieses "xinit" hält wohl eine eigene Verbindung. Der X-Server sieht also immer mindestens einen Client. Das sollte aber eigentlich garnichts ausmachen. Der X-Server sollte eigentlich weiterlaufen...

M-Reimer · 13. Februar 2014

Hat etwas gedauert bis ich dazu gekommen bin und bis ich den Fehler auch wirklich gefunden habe, aber jetzt glaube ich die Ursache gefunden zu haben.

Komischerweise hat "SUSP" und "RESU" bei mir funktioniert. Erst ein "DETA" hat den VDR gekillt. Mögliche Lösung:

Packt mal in eure "runvdr.conf" folgendes als "XSERVER" rein:

Code

XSERVER="/usr/bin/X -nolisten tcp -noreset"

Ohne die Option "-noreset" beendet sich der X-Server wenn der letzte Client sich abmeldet. Da auf unserem X-Server erstmal nur der VDR aktiv ist, ist das keine gute Idee.

Ich könnte das jetzt irgendwie in der runvdr reinfrickeln, ich tendiere aber dazu lieber die Example-runvdr und die man-Page anzupassen und eine Notiz ins Changelog zu packen, denn ich finde der Benutzer sollte die Kontrolle über diese Einstellung behalten. Oder wie seht ihr das?

Bitte prüfen ob das auch bei euch funktioniert.

iNOB · 13. Februar 2014

Das steht bei mir schon seit Ewigkeiten so drin?!

Gruß
iNOB

M-Reimer · 14. Februar 2014

Du warst auch nicht gefragt

Die Frage richtet sich an die, die Probleme beim Suspend/Detach hatten.

M-Reimer · 19. Februar 2014

Ich habe mal noch etwas gebastelt.

Das mit dem "noreset" ist jetzt dokumentiert und ergänzend habe ich die Möglichkeit eingebaut, dass für "XSERVER" einfach "1" gesetzt werden kann. Wenn man dies tut, dann wird mit Standardeinstellungen gestartet. Also mit System-Xorg.conf und den minimal nötigen Parametern.

http://projects.vdr-developer.…vdr-extreme.git?h=noxinit

dad401 · 4. April 2014

Zitat von Mreimer

Bitte prüfen ob das auch bei euch funktioniert.

Ich habe den Aufruf geändert und der Absturz ist nicht mehr vorhanden. SHDD lässt sich nun wieder sauber anhalten und fortsetzen. Ich werde die neue Version beibehalten...falls sich doch noch was anderes bemerkbar macht.

Danke für das Auffinden der Ursache,
Marcus

Neues X server Handling in der runvdr-extreme. Bitte um Tester.

Jetzt mitmachen!

Teilen