speicherzugriffsfehler bei atom

chha · 2. November 2009

Leute,
Ich versuche seit einem Monat einen VDR Client auf einem Atom mit ION Chipsatz aufzusetzen.
Die Konfiguration hab ich von einem anderen Client mit Celeron kopiert. Dort läuft sie einigermaßen.
Betriebssystem ist SuSE 11.0

Alles kompiliert ohne Probleme.
Wenn das runvdr Script dann tatsächlich VDR startet meldet der aber einen Speicherzugriffsfehler und runvdr versucht einen Restart.

Hat jemand eine Idee was das sein könnte?
In anderen Threads wurde empfohlen sudo zu benutzen. Ich habs aber nicht auf die Reihe bekommen. Vieleicht benutz ich sudo falsch.

VDR wird für den NIS User vdr_olympia:vdr kompiliert und runvdr wird als root gestartet.

Vielen Dank,
Christian

gda · 2. November 2009

Zitat

Original von chha
Ich versuche seit einem Monat einen VDR Client auf einem Atom mit ION Chipsatz aufzusetzen.

Ein Arbeitskollege hat das Selbe vergangenes Wochenende unter Benutzung meines Repositories gemacht. Ist dir nicht aufgefallen, dass SuSE nicht gerade die am Besten unterstützte VDR-Distribution ist? Da wird es etwas schwierig sachkundige Hilfe zu bekommen.

Gerald

FireFly · 2. November 2009

Zitat

Original von gda
Ist dir nicht aufgefallen, dass SuSE nicht gerade die am Besten unterstützte VDR-Distribution ist? Da wird es etwas schwierig sachkundige Hilfe zu bekommen.

Qautsch. Ich benutze seit Jahren ausschließlich Suse und habe keinerlei Probleme - bis auf die, die auch andere Distris haben.

chha: Das kann alles mögliche sein und kann Dir unter Ubuntu/Debian etc. genauso passieren. Hast Du ein Log vom Absturz (z.B. in /var/log/messages)? Ohne ist das nämlich reine Raterei. Ansonsten starte mal ganz ohne Plugins, um die schon mal auszuschließen.

googles · 2. November 2009

Zitat

Original von gda
Da wird es etwas schwierig sachkundige Hilfe zu bekommen.

Ohne Logs garantiert

chha · 3. November 2009

Ich hab 1.7.9 nochmal neu kompiliert. Er reagiert aber immer noch gleich.
Ganz ohne plugins mochte er gar nicht. Es ist nur ein Client ohne DVB Karte - vielleicht war das der Grund.
Ich benutze hier xineliboutput.
runvdr.log.txt ist das transcript.
runvdr.messages.txt ist das Sytemlog.

Heute kann ich nicht mehr weiter machen. Vielleicht komm ich am Dienstag dazu weniger Plugins auszuprobieren.

Christian

slime · 3. November 2009

hast du den vdr auf dem celeron oder auf dem atom compiliert?
auch wenn ich das eher nicht glaube, aber es könnte ja sein, das der celeron features unterstützt, die der atom nicht hat.
ich würde da zum testen mal einen reinen i386-build machen, oder noch besser, direkt auf dem atom compilieren.

chha · 3. November 2009

slime,
Natuerlich hab ich alles neu kompiliert.
Erstens ist es ja trivial und zweitens ist der Celeron ein 32bit Rechner der Atom aber 64bit.

Danke slime!
Ich bin fast sicher, dass es irgend so ein dummer Fehler ist.

Christian

FireFly · 3. November 2009

Hi,

im Log findet sich folgendes (leicht gekürzt):

Code

Nov  3 11:36:26 olympia vdr: [18193] starting plugin: xineliboutput
Nov  3 11:36:26 olympia vdr: [18201] Local decoder/display (cXinelibThread) thread started (pid=18193, tid=18201)
Nov  3 11:36:26 olympia vdr: [18201] [xine..put] xineliboutput: plugin file is /usr/local/src/VDR/PLUGINS/lib/libvdr-xineliboutput.so.1.7.9
Nov  3 11:36:26 olympia vdr: [18201] [vdr-sxfe]  sxfe_display_open(width=720, height=576, fullscreen=1, display=/dev/fb0)
Nov  3 11:36:26 olympia vdr: [18201] [vdr-sxfe]  sxfe_display_open: failed to connect to X server (/dev/fb0)
Nov  3 11:36:26 olympia vdr: [18201] [xine..put] cXinelibLocal::Action - fe->fe_display_open ok
Nov  3 11:36:26 olympia vdr: [18201] [xine..put] cXinelibLocal::Action - xine_init
Nov  3 11:36:26 olympia vdr: [18201] [xine-vo  ] wire_video_driver() FAILED (vo_driver != vos_driver)
Nov  3 11:36:26 olympia vdr: [18201] [vdr-fe]    wire_video_driver() for osdscaler failed
Nov  3 11:36:26 olympia vdr: [18201] [xine-vo  ] wire_video_driver() FAILED (vo_driver != vos_driver)
Nov  3 11:36:26 olympia vdr: [18201] [vdr-fe]    wire_video_driver() for osdreorder failed
Nov  3 11:36:26 olympia kernel: Local decoder/d[18201]: segfault at 0 ip 0 sp 4340bfc8 error 14 in vdr[400000+135000]

Alles anzeigen

Der Fehler kommt also von xineliboutput und er kann sich nicht an einen X-Server connecten (Framebuffer Device /dev/fb0).
Mehr kann ich dazu aber nicht sagen mangels Erfahrung mit Soft-Decodern.

FireFly

chha · 5. November 2009

Firefly,
das hoert sich nach einer Neuinstallation vom X-Server an.

Vielen Dank. Ich sag Bescheid wenn ich mehr weiss.

Gruss,
Christian

gda · 5. November 2009

Zitat

Original von FireFly
Nov 3 11:36:26 olympia vdr: [18201] [vdr-sxfe] sxfe_display_open(width=720, height=576, fullscreen=1, display=/dev/fb0)

Du versuchst mit dem X-Frontend vdr-sxfe auf einen Framebuffer zuzugreifen? Das ist doch Unsinn. Was willst du denn jetzt, X-Server oder Framebuffer?
Dann sehen wir weiter. Ich empfehle übrigens den X-Server.

Zitat

Original von FireFly
Qautsch. Ich benutze seit Jahren ausschließlich Suse und habe keinerlei Probleme - bis auf die, die auch andere Distris haben.

Wieso ist das Quatsch? Ich habe doch nicht gesagt, dass SuSE Probleme macht, ich habe nur gesagt, dass es schwierig ist sachkundige Hilfe zu bekommen. Bis jetzt sehe ich noch keinen SuSE-Anhänger der Ihm entscheidend helfen konnte.

Gerald

netvista-fan · 5. November 2009

Scheint ein local frontend zu sein das sich nicht zu x connecten kann, falsche rechte, falsches display, x-server noch nicht am laufen etc.

setz local auf none und der vdr wird starten.

wenn Du nicht per streamdev client/server streamst sondern per xineliboutput braucht keinen vdr auf dem client, nur vdr-sxfe würd dann reichen...

gda · 5. November 2009

Zitat

Original von netvista-fan
Scheint ein local frontend zu sein das sich nicht zu x connecten kann, falsche rechte, falsches display, x-server noch nicht am laufen etc.

Ganz sicher ist display falsch. Da würde ich eher display=:0 erwarten.

Gerald

FireFly · 5. November 2009

Zitat

Original von gda

Wieso ist das Quatsch? Ich habe doch nicht gesagt, dass SuSE Probleme macht, ich habe nur gesagt, dass es schwierig ist sachkundige Hilfe zu bekommen. Bis jetzt sehe ich noch keinen SuSE-Anhänger der Ihm entscheidend helfen konnte.

Das mit dem X-Serer hat ihm schon mal entscheidend weitergeholfen, auch wenn das noch nicht direkt zur Lösung geführt hat. Und das ewige Genöle "nimm debian|ctvdr|<distri-deiner-wahl>" hilft niemandem weiter.

gda · 5. November 2009

Zitat

Original von FireFly
Und das ewige Genöle "nimm debian|ctvdr|<distri-deiner-wahl>" hilft niemandem weiter.

Da hast du Recht, deshalb habe ich das ja auch nicht gemacht.

Gerald

netvista-fan · 5. November 2009

Und ums nochmal klar zu sagen...
der Fehler wird wohl nicht am x-server liegen, sondern daran dass das local frontend nicht auf den x-server kann.
Umstellen auf local=none und remote=37890, vdr-sxfe manuell im x-server!!! terminal starten und im groben könnte es dann laufen.
Und diese Sache dürfte auch bei jeder Distri gleich sein.
Wenn es doch local sein soll, x muss vor dem vdr starten, vdr-user muss zugriff auf x haben, display muss angegeben werden.

chha · 9. November 2009

Der X-server scheint tatsächlich in Ordnung zu sein. Ich werd' einfach noch mal von vorne anfangen und das Betriebssystem neu installieren.

Den VDR remote laufen zu lassen kommt für mich nicht in Frage da jeder Client andere Hardware hat und dementsprechend andere Plugins braucht.

Danke für die Geduld.

baben_j · 12. November 2009

Hallo,

ich habe das gleiche Problem wenn ich den VDR über "runvdr" als user "vdr" starten will.
Habe den User "vdr" anhand der entsprechenden Anleitung angelegt.
Wenn ich den VDR als user "root" starte kein Problem.
Das scheint bei mir also ein Rechteproblem beim User "vdr" zu sein.
Ich weiss aber nicht welches Verzeichnis ich dem User "vdr" noch zuweisen muss:
"chown -R vdr:vdrdaem /?/?..."
Die in der "runvdr" verwendeten Verzeichnisse habe ich mit "chown -R vdr:vdrdaem "Verzeichnis" zugewiesen
Fehlermeldung bei User "vdr":

Code

linux-vdr3:/usr/local/bin # ./runvdr
Hallo
./runvdr: line 59:  5871 Speicherzugriffsfehler  /usr/local/bin/./vdr -t /dev/tty8 -w 60 -c /etc/vdr -E /var/vdr --vfat -s /usr/local/bin/vdrpoweroff.sh -L /home/juergen/Programme/vdr_files/VDR/PLUGINS/lib -P streamdev-client -P 'xine -r'
Do 12. Nov 17:43:59 CET 2009
restarting VDR

Ohne das PLUGIN "xine" kann ich den VDR unter User "vdr" starten.
Betriebssystem ist "openSUSE 11.1"
Meine "runvdr" sieht so aus:

Bash

#!/bin/sh


# runvdr: Loads the DVB driver and runs VDR
#
# If VDR exits abnormally, the driver will be reloaded
# and VDR restarted.
#
# Since this script loads the DVB driver, it must be started
# as user 'root'. Add the option "-u username" to run VDR
# under the given user name.
#
# Any command line parameters will be passed on to the
# actual 'vdr' program.
#
# See the main source file 'vdr.c' for copyright information and
# how to reach the author.
#
# $Id: runvdr 1.16 2006/02/04 15:20:48 kls Exp $


#DVBDIR="../DVB/driver"
BINDIR="/usr/local/bin"
#BINDIR="/etc/vdr"
#PLUGINDIR="/usr/local/src/vdr_files/VDR/PLUGINS/lib"
PLUGINDIR="/home/juergen/Programme/vdr_files/VDR/PLUGINS/lib"
#PLUGINS="$PLUGINS -P 'xine -r' -P streamdev-client -P 'xineliboutput --local=none --remote=37890 --primary'"
#PLUGINS="$PLUGINS -P 'xine -r' -P streamdev-client -P 'xineliboutput --local=none --remote=37890 --primary'"
PLUGINS="$PLUGINS -P streamdev-client -P 'xine -r'"
# fuer VDR 1.4.x
#export LANG=de_DE.iso8859-1
#export LC_CTYPE=de_DE.iso8859-1
# fuer VDR 1.5.x
export LANG=de_DE.UTF-8
export LC_CTYPE=de_DE.UTF-8
#export HOME="/root"
#export HOME="/vdr"


VDRPRG="/usr/local/bin/./vdr"
#VDRPRG="/etc/vdr/./vdr"
VDRCMD="$VDRPRG -t /dev/tty8 -w 60 -c /etc/vdr -E /var/vdr \
                --vfat -s /usr/local/bin/vdrpoweroff.sh  \
		-L $PLUGINDIR  $PLUGINS \ "
	#	-r '/usr/local/bin/noadcall.sh' "


LSMOD="`/sbin/lsmod | grep -w '^dvb' | wc -l`"
KILL="/usr/bin/killall -q -TERM"
# rmmod cdfs.ko


# Load driver if it hasn't been loaded already:
if [ $LSMOD -eq 0 ] ; then
#   (cd $DVBDIR; make insmod)
#    /etc/init.d/dvb start
#    insmod /usr/local/src/vdr_files/cdfs-2.6.12/cdfs.ko
   echo "Hallo" 
  fi


while (true) do
      eval $VDRCMD
      if test $? -eq 0 -o $? -eq 2; then exit; fi   <--- das ist Zeile 59
      date
      echo "restarting VDR"
      $KILL $VDRPRG
      sleep 10
#      (cd $DVBDIR; make rmmod; make insmod)
#      /etc/init.d/dvb start

      date
      done

Alles anzeigen

In /"var/log/messages" steht:

Code

ov 12 17:43:58 linux-vdr3 vdr: [6067] VDR version 1.6.0 started
Nov 12 17:43:58 linux-vdr3 vdr: [6067] switched to user 'vdr'
Nov 12 17:43:58 linux-vdr3 vdr: [6067] codeset is 'UTF-8' - known
Nov 12 17:43:58 linux-vdr3 vdr: [6067] found 23 locales in /home/juergen/Programme/vdr_files/VDR/locale
Nov 12 17:43:58 linux-vdr3 vdr: [6067] loading plugin: /home/juergen/Programme/vdr_files/VDR/PLUGINS/lib/libvdr-streamdev-client.so.1.6.0
Nov 12 17:43:58 linux-vdr3 vdr: [6067] loading plugin: /home/juergen/Programme/vdr_files/VDR/PLUGINS/lib/libvdr-xine.so.1.6.0
Nov 12 17:43:58 linux-vdr3 vdr: [6067] loading /etc/vdr/setup.conf
Nov 12 17:43:58 linux-vdr3 vdr: [6067] loading /etc/vdr/sources.conf
Nov 12 17:43:58 linux-vdr3 vdr: [6067] loading /etc/vdr/diseqc.conf
Nov 12 17:43:58 linux-vdr3 vdr: [6067] loading /etc/vdr/channels.conf
Nov 12 17:43:58 linux-vdr3 vdr: [6067] loading /etc/vdr/svdrphosts.conf
Nov 12 17:43:58 linux-vdr3 vdr: [6067] loading /etc/vdr/keymacros.conf
Nov 12 17:43:59 linux-vdr3 vdr: [6068] video directory scanner thread started (pid=6067, tid=6068)
Nov 12 17:43:59 linux-vdr3 vdr: [6069] video directory scanner thread started (pid=6067, tid=6069)
Nov 12 17:43:59 linux-vdr3 vdr: [6068] video directory scanner thread ended (pid=6067, tid=6068)
Nov 12 17:43:59 linux-vdr3 vdr: [6069] video directory scanner thread ended (pid=6067, tid=6069)
Nov 12 17:43:59 linux-vdr3 vdr: [6067] reading EPG data from /var/vdr/epg.data
Nov 12 17:43:59 linux-vdr3 vdr: [6067] probing /dev/dvb/adapter0/frontend0
Nov 12 17:43:59 linux-vdr3 vdr: [6071] tuner on device 1 thread started (pid=6067, tid=6071)
Nov 12 17:43:59 linux-vdr3 vdr: [6072] section handler thread started (pid=6067, tid=6072)
Nov 12 17:43:59 linux-vdr3 vdr: [6067] found 1 video device
Nov 12 17:43:59 linux-vdr3 vdr: [6067] initializing plugin: streamdev-client (0.5.0-pre): VTP Streaming Client
Nov 12 17:43:59 linux-vdr3 vdr: [6067] initializing plugin: xine (0.9.3): Software based playback using xine
Nov 12 17:43:59 linux-vdr3 vdr: [6073] XineRemote control thread started (pid=6067, tid=6073)
Nov 12 17:43:59 linux-vdr3 vdr: [6073] Entering cXineRemote thread
Nov 12 17:43:59 linux-vdr3 vdr: [6067] setting primary device to 1
Nov 12 17:43:59 linux-vdr3 vdr: [6067] device 1 has no MPEG decoder
Nov 12 17:43:59 linux-vdr3 vdr: [6067] trying device number 2 instead
Nov 12 17:43:59 linux-vdr3 vdr: [6067] setting primary device to 2
Nov 12 17:43:59 linux-vdr3 kernel: vdr[6067]: segfault at 0 ip 00007f872c2725e9 sp 00007fff6d919bf0 error 4 in libc-2.9.so[7f872c20d000+14f000]

Alles anzeigen

MfG
Jürgen B.

3PO · 12. November 2009

Zitat

Original von baben_j

Code

[...]
Nov 12 17:43:59 linux-vdr3 kernel: vdr[6067]: segfault at 0 ip 00007f872c2725e9 sp 00007fff6d919bf0 error 4 in libc-2.9.so[7f872c20d000+14f000]

Da würde ich mal ein Backtrace ziehen, evtl. sieht man ja dann mehr.

speicherzugriffsfehler bei atom

Jetzt mitmachen!

Teilen