Verursacht das Neuladen der Kernelmodule durch runvdr Probleme?

    Hi,


    ich habe folgendes Problem beobachtet. Aus irgendwelchen Gründen schiebt der vdr Panik und beendet sich mit einem Exitcode ungleich Null. (Kann sein, dass das mit meinem Recording-Hook zusammenhängt, ist aber für die weiteren Konsequenzen unerheblich.) Das veranlasst runvdr, den Wachhund, erstmal die DVB-Kernelmodule zu entladen und neu zu laden und anschließend den vdr neu zu starten.



    Das ist zwar eine nette Idee, führt aber zumindest bei mir zu Problemen. Sobald der vdr Videodaten aufzeichnen soll, kann er /dev/dvb/adapter0/dvr0 nicht öffnen.



    Dieser Zustand ist nur noch durch einen Neustart des Rechners zu beheben. Man kann den Zustand auch künstlich herbeiführen, indem man den vdr mit kill -9 beendet, denn auch dann lädt runvdr die DVB-Module neu. Wenn der vdr sauber neu gestartet wird, tritt das Problem nicht auf.


    Daher nehme ich an, dass es meinem Kernel irgendwie nicht gut tut, wenn die DVB-Module neu geladen werden, oder zumindest der Zusammenhang mit /dev/dvb/adapter0/dvr0 dadurch verloren geht oder so.


    Ist das Problem bekannt? Kann man runvdr abgewöhnen, die DVB-Module neu zu laden? Ich habe in den Manpages und den Initscripten und Configdateien nichts derartiges gefunden.


    Mein System: Debian lenny mit Stock-Kernel linux-image-2.6.26-1-686 (2.6.26-8), vdr (1.6.0-6ctvdr2) von e-tobi.net, Hauppauge Nova-S-Plus DVB-S.


    Grüße, Kolja.

    sowas ähnliches gab es hier mal:
    http://fixunix.com/kernel/1357…6-22-worked-2-6-21-a.html
    das sollte aber in einem 2.6.26 längst gefixt sein.


    prüf doch mal, ob nach dem Laden von cx88-dvb das device file /dev/dvb/adapter0/dvr0 wirklich fehlt

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    Vorher:


    Code
    server:/# ls -l /dev/dvb/adapter0/
total 0
crw-rw---- 1 root video 212, 4 2008-10-23 22:37 demux0
crw-rw---- 1 root video 212, 5 2008-10-23 22:37 dvr0
crw-rw---- 1 root video 212, 3 2008-10-23 22:37 frontend0
crw-rw---- 1 root video 212, 7 2008-10-23 22:37 net0
server:/# cat /dev/dvb/adapter0/dvr0
^C

    Nachher:


    Code
    server:/# ls -l /dev/dvb/adapter0/
total 0
crw-rw---- 1 root video 212, 4 2008-10-24 22:30 demux0
crw-rw---- 1 root video 212, 5 2008-10-24 22:30 dvr0
crw-rw---- 1 root video 212, 3 2008-10-24 22:30 frontend0
crw-rw---- 1 root video 212, 7 2008-10-24 22:30 net0
server:/# cat /dev/dvb/adapter0/dvr0
cat: /dev/dvb/adapter0/dvr0: No such device


    Sieht aus, wie das Problem, welches Du verlinkt hast.


    Seit wann sollte das denn gefixt sein? Debian lenny ist doch ziemlich dicht am aktuellen 2.6.26er Kernel, oder?


    Ansonsten könnte man vielleicht runvdr dahingehend ändern, dass auch dvb_core neu geladen wird.

    die Frage ist, ob es überhaupt ein Bug ist. Da hätte es eigentlich viel mehr Berichte, insbesodnere in der linuxtv-ML geben müssen.


    Kannst du ein aktuelles v4l-dvb hg für Deinen Kernel kompilieren? mal schauen, ob das Problem mit aktuellen Treiber auch noch auftritt. Wenn ja, ist es aber offenbar spezifisch für cx88-dvb.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    hallo, ich hab genau den selben kernel, die selbe sat karte, und dass selbe problem (bei mir laufen aber die multiprot. treiber)
    durch dass neu laden der dvb-core treiber geht es meistens wieder.


    auf nem älteren kernel hatte ich dass problem nicht,
    da ich derzeit keine zeit habe konnte ich mich nicht damit befassen.
    (dacht vorab dass es an den multiprot. treiber, da die vom april 2008 sind)


    gruss, onur

    Ich habe gerade testweise 2.6.25-2-686 (2.6.25-7) gebootet, und damit tritt das Problem bei mir auch nicht mehr auf, aber aus einem ganz einfachen Grund: die Module werden gar nicht mehr neu geladen! (Das sieht man im syslog und mit dmesg, onur, kannst Du das bei Dir bestätigen?) Außerdem glaube ich nun auch verstanden zu haben, worin das Problem bei 2.6.26-1-686 (2.6.26-8) besteht.


    Die Ursache für diesen Unterschied zwischen beiden Kerneln hängt mit der Strategie zusammen, mit der /usr/sbin/runvdr ermittelt, welche Module zu entladen sind, und den unterschiedlichen Abhängigkeiten zwischen den Modulen bei den beiden Kerneln.


    Die Funktion get_modulenames() filter zunächst per awk aus lsmod alle Module aus, die dvb_core nutzen, kehrt deren Reihenfolge um, und fügt der Liste noch dvb_core hinzu. Beim Emergency-Neustart des vdr werden die Module in der so erzeugten Liste der Reihe nach mit rmmod entladen.


    Das führt bei 2.6.25 zu folgendem Effekt:


    Wie man sieht, findet der aus get_modulenames() entnommene Filter nur ein Modul, videobuf_dvb, und wenn dieses und anschließend dvb_core entladen werden soll, passiert gar nichts, weil die Abhängigkeiten nicht korrekt berücksichtigt wurden.


    Mit 2.6.26 sieht der Effekt dank veränderter Abhängigkeiten etwas anders aus:


    Wie man sieht, findet der Filter nun zwar alle relevanten Module, aber auch hier ist die Reihenfolge unbrauchbar, so dass am Ende nur cx88_dvb entladen wird.


    Es sieht so aus, als sei in get_modulenames() implementierte Ansatz nicht ausreichend, um komplexere Abhängigkeiten zwischen den Modulen zu berücksichtigen.


    Vielleicht sollte man auf diesen Automatismus verzichten, und den Leuten, die aus Stabilitätsgründen das Neuladen der Module brauchen, die Möglichkeit anbieten, die richtige Liste von Modulen in der richtigen Reihenfolge in einer Config-Datei einzutragen.


    Oder man schreibt Code, der die Dependencies in lsmod komplett auswertet und eine Liste in der richtigen Reihenfolge erzeugt. Das dürfte aber nicht ganz trivial sein.


    Das Script stammt doch von Tobi, oder? Kann Tobi mal seine Meinung dazu sagen?

    Hi,


    wenn Du ein Script haben willst, daß wirklich alle DVB-Module entladen kann, mußt Du das von LinuxTV nehmen. Wenn das zu kompliziert ist oder man aus irgendwelchen Gründen kein Perl benutzen will, kann man auch die Entladereihenfolge, die das Script verwendet, in einem primitiven Script benutzen. Es funktioniert dann aber nur für die entsprechenden Karten. Wenn ich das Script aufrufe, erhalte ich folgenden Output:


    Das sind zwar jetzt zwei DVB-C Karten. Das Script funktioniert aber für alle DVB-Karten.


    Scripte, die nur über Abhängigkeiten arbeiten, können nicht alle DVB-Module entladen. Frontend-Module z.B. werden dynamisch geladen, sodaß keine Abhängigkeiten entstehen. Lsmod zeigt bei mir keine Abhängigkeiten für stv0297 und tda10021:

    Das Script muß wissen, welche abhängigkeitslosen Module entladen werden müssen.

    Gruß
    e9hack

    hallo,
    kann ich bestätigen, ich hab mein mainboard gewechselt, mit dem alten kernel lief der RTL8111C netzwerkchip nicht. hab dann einfach nen neuen kernel genommen, welcher genau die beschriebenen symptome zeigt.


    zur info:
    mein vdr läuft 24/7, als streaming server,
    da es vorkommen kann dass die treiber abstürzen habe ich den vdr um eine restart funktion erweitert.
    mein vdr macht alle 3 stunden einen restart, falls mindestens 5 mintuen kein stream oder aufnahme aktiv war.....
    weiters habe ich geändert dass ein defekter channels.conf eintrag nicht zu einem neustart führt,
    und dass ein timer den vdr nicht in einer endlosschleife neustarten kann.
    wenn eine timer-aufnahme einen neustart verursacht schreibe ich einfach ne leere 999.vdr in den jeweiligen video ordner,
    beim nächsten mal schaut der vdr ob die datei da ist, wenn ja dann macht er keinen erneuten vdr neustart.

    Kacke, ist das kompliziert. Eine Lösung für mein System habe ich jetzt natürlich, ich kann die Liste der Module einfach hardcoden, aber ein Patch, der das Problem allgemeingültig löst, scheint alles andere als trivial zu sein. Das Perl-Script von v4l funktioniert übrigens nicht so ohne weiteres, wenn man nur ein Standard-Kernel-Paket installiert hat.

    Zitat

    Original von kolja
    Kacke, ist das kompliziert. Eine Lösung für mein System habe ich jetzt natürlich, ich kann die Liste der Module einfach hardcoden, aber ein Patch, der das Problem allgemeingültig löst, scheint alles andere als trivial zu sein.


    Nicht wirklich. Folgendes Script sollte alle DVB-Module entladen, wenn sie nicht mehr benutzt werden (RefCount=0):

    Man sollte das Abtrennen von Pfad und Extension von den Modulnamen irgendwie anders machen. 1000x basename aufrufen dauert etwas.


    Gruß
    e9hack

    Danke, damit muss ich mal herumspielen. Hat noch den Nachteil, dass Sound-Treiber auch entladen werden. Aber sich nur auf drivers/media/dvb zu beschränken, reicht scheinbar auch nicht.


    Was basename angeht, das braucht man tatsächlich nicht:


    Code
    # DVB-Module ermitteln; Pfad und Extension abtrennen; '-' in '_' umwandeln
modules=$(find /lib/modules/$(uname -r)/kernel/drivers/media -type f|sed "s/\([^/]*\/\)*\([^/]*\)\.ko/\2/g;s/-/_/g")
    Zitat

    Original von kolja
    Danke, damit muss ich mal herumspielen. Hat noch den Nachteil, dass Sound-Treiber auch entladen werden.


    In drivers/media dürfen sich nur Dvb- bzw. Video-Module befinden. Da geht irgendwas anderes schief. Du solltest mal die Liste mit den DVB-Modulen ausgeben lassen und mit den fälschlicherweise entladenen Sound-Modulen vergleichen.


    Zitat


    Was basename angeht, das braucht man tatsächlich nicht:


    Code
    # DVB-Module ermitteln; Pfad und Extension abtrennen; '-' in '_' umwandeln
modules=$(find /lib/modules/$(uname -r)/kernel/drivers/media -type f|sed "s/\([^/]*\/\)*\([^/]*\)\.ko/\2/g;s/-/_/g")


    Mit sed konnte ich mich noch nie anfreunden.


    Ich habe das Script noch ein klein wenig vereinfacht:

    Außerdem werden noch die nicht entladenen Module angezeigt.


    Gruß
    e9hack

    prima vielen Dank, habe ebenfalls das Problem mit Debian lenny 2.6.26 und dem VDR von e-tobi. Das Script hilft. Hab es einfach mal in die funktion unload_dvb_modules in runvdr eingebaut. Ist jetzt sicher ein bisschen doppelt, aber Hauptsache es funktioniert.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden