TBS 6982 und VDR bringen XEN- und KVM-Host ohne Fehlerausgabe zum Stillstand. Was tun?

  • Hallo zusammen,


    ich nutze den VDR seit vielen Jahren mit einer alten FF-Karte mit SAA7146-Chipsatz in einer Xen-Umgebung über diverse VDR-/OpenSuse-Versionen hinweg als konsolenbasierten Aufnahmeserver. Seit dem Austausch von Hauptplatine, Speicher, Festplatte und Sat-Karte friert mein Hostsystem nach dem Start des VDR im Gastsystem nach einer gewissen Zeit (4 Minuten bis 20 Stunden) komplett ein. Dummerweise jedoch ohne einen Hinweis in den Host-/Gast-Logs oder auf dem Schirm zu hinterlassen. Ich bin mittlerweile restlos ratlos und wende ich mich daher mal hilfesuchend an dieses Forum.


    Die aktuelle Hardware:
    - ASRock 970 Extreme4, BIOS P2.60, 6-Kern AMD-CPU, 16GB RAM
    - 2x3TB Raid 1 für Hostsystem; hierauf liegt die Systempartition des VDR-Gastsystems (LVM-LV)
    - 2x4TB durchgereicht an VDR-Gast
    - 1xTBS 6982 PCIe Duat-Sat-Karte, durchgereicht an VDR-Gast


    Solange ich den VDR nicht starte, läuft der Host mit mehreren Linux-/Win-Gästen über Wochen stabil und problemlos. Ich gehe daher nicht von einem Hardwarefehler aus.


    Ich habe als Hostsystem OpenSuse 12.3 XEN, OpenSuse 13.1 XEN und nun zu guter Letzt auch OpenSuse 13.1 mit einer KVM-Virtualisierung ausprobiert. Als Gäste kamen OpenSuse 12.3 und 13.1 zum Einsatz. Alles problemlos, solange der VDR nicht länger mit der TBS-Karte kommunizieren muss.


    Es wurde sowohl der aktuelle TBS-Treiber als auch die OpenSource-Alternative (https://github.com/ljalves/linux_media/wiki) probiert: Stets das gleiche Problem.


    TVHeadend und MythTV kommen mit der Karte und dem zur Zeit benutzten OpenSource-Treiber übrigens bestens über mehrere Tage klar: EPG-Scanning, PID-Aktualisierungen, Aufnahmen - was das Herz begehrt. Dummerweise begeistern mich beide Programme nicht sonderlich - ich hätte gerne den VDR :]


    Probiert habe ich bislang:
    - VDR-Versionen 1.7.X und 2.0.6
    - Ausschluss von HD-Sendern
    - Zusammenraffen der channels.conf auf 10 SD-TV-Sender
    - Deaktivierung der Aktualisierungen über UpdateChannels = 0
    - Begrenzung auf 1 Frontend bzw. Wechsel des genutzten Frontends


    Leider alles erfolglos. Setze ich jedoch wieder die alte FF-Karte ein, läuft der VDR wie geschmiert. Einen Fehler in den Configs, in einem der wenigen Plugins oder der beiden durchgereichten Platten kann ich mir daher nicht vorstellen.


    Kurzum: Von drei PVR-Lösungen in 2 Virtualisierungsumgebungen schafft es nur der VDR im Zusammenspiel mit dieser Karte das System ohne Ausgabe eines Fehlers komplett einzufrieren.


    Kann mir jemand sagen, wo ich ansetzen kann? Ich kenne mich leider mit Debugging unter Linux überhaupt nicht aus.


    Vielen Dank!
    Sven

  • Wie wäre es, es mal ohne Virtualisierung zu versuchen?

  • Wie wäre es, es mal ohne Virtualisierung zu versuchen?


    Um auszuschließen, dass es an der Virtualisierung liegt? Ist das denn nicht durch den langen Betrieb auf Xen-Basis und den Test auf KVM-Basis so gut wie ausgeschlossen? Auch die Tatsache, dass TVHeadend und MythTV mit der Karte in einer virtualisierten Maschine bestens arbeiten, deutet doch darauf hin, dass das Problem beim VDR liegt.


    Ich werde es am WE aber gene mal ausprobieren. Eine Dauerlösung ist es aber nicht, schließlich trenne ich die Systeme ja nicht ohne Grund.

  • DVB Treiber werden nicht dafür entwickelt, durchgereicht zu werden. Also kann es funktionieren, muss aber nicht.

  • Also bei mir läuft VDR in einer virtuellen XEN MAschine mit PCI Passhthrough von 2 FF Technotrend Karten seit Jahren. Immer wieder mal gibts Probleme, meistens hilft es die Karten der virt. Maschine eg- und wieder hinzukonfigurieren.


    Ein ähnlich Problem wie Du hatte ich mal, durch explizite Zuweiseung des ersten Cores (4-Cores habe ich) an Dom0 hat es sich gelöst. War wohl ein Deadlock Problem mit den INterrupts.


    Kannst es ja mal ausprobieren...

  • DVB Treiber werden nicht dafür entwickelt, durchgereicht zu werden. Also kann es funktionieren, muss aber nicht.


    Hat leider nicht funktioniert. Habe auf dem Xen-Host (also in Dom0) den aktuellsten Treiber von TBS kompiliert und den VDR 2.0.6 um 12:52 gestartet. Hier die letzten Log-Einträge:

    Code
    1. 2014-11-08T13:35:29.286861+01:00 server0 vdr: [2581] changing pids of channel 2319 from 0+0=0:0:0:0 to 167+167=2:108=fra@4:0:53
    2. 2014-11-08T13:35:29.288613+01:00 server0 vdr: [2581] changing caids of channel 2319 from 0 to 500,1811,1863,100
    3. 2014-11-08T13:35:29.395298+01:00 server0 vdr: [2581] changing pids of channel 2317 from 0+0=0:0:0:0 to 165+165=2:100=fra@4:0:47
    4. 2014-11-08T13:35:29.396966+01:00 server0 vdr: [2581] changing caids of channel 2317 from 0 to 500,1811,1863,100
    5. 2014-11-08T13:35:44.246812+01:00 server0 vdr: [2577] frontend 0/0 timed out while tuning to channel 0, tp 212630
    6. 2014-11-08T13:35:59.610694+01:00 server0 vdr: [2581] changing pids of channel 1035 from 0+0=0:0:0:0 to 163+8191=2:400=esl@4,254=eng@4:0:0
    7. 2014-11-08T13:35:59.641584+01:00 server0 vdr: [2581] changing pids of channel 1036 from 0+0=0:0:0:0 to 163+163=2:400=esl@4,254=eng@4:0:0


    Dann war Feierabend bzw. absoluter Stillstand und es half nur noch ein Reset. Das kurz vor Stillstand aufgeführte "timed out"-Problem ist während des Tests nur einmal aufgetreten. Ich kenne das von meiner alten FF-Karte, wo es allerdings nie zu derarigen Problemen geführt hat.


    Also bei mir läuft VDR in einer virtuellen XEN MAschine mit PCI Passhthrough von 2 FF Technotrend Karten seit Jahren. Immer wieder mal gibts Probleme, meistens hilft es die Karten der virt. Maschine eg- und wieder hinzukonfigurieren.
    Ein ähnlich Problem wie Du hatte ich mal, durch explizite Zuweiseung des ersten Cores (4-Cores habe ich) an Dom0 hat es sich gelöst. War wohl ein Deadlock Problem mit den INterrupts.
    Kannst es ja mal ausprobieren...


    Kann ich nur bestätigen: Alte FF-Karte unter Xen jahrlang weitgehend problemloser Betrieb. Dein Ansatz mit der Kernzuweisung ist interessant. Macht dieser Test jetzt (also nach dem heutigen, ebefalls erfolglosen Test in Dom0) noch Sinn? Wenn ich ohne eine virtuelle Maschine innnerhalb einer Dom0 die gleichen Absturzprobleme habe, ist das doch wie ein Absturz auf einem nicht virtualisierem System. Oder irre ich mich hier?

  • Macht dieser Test jetzt (also nach dem heutigen, ebefalls erfolglosen Test in Dom0) noch Sinn? Wenn ich ohne eine virtuelle Maschine innnerhalb einer Dom0 die gleichen Absturzprobleme habe, ist das doch wie ein Absturz auf einem nicht virtualisierem System. Oder irre ich mich hier?


    Sehe ich auch so, wenns ohne Virtualisierung nicht läuft, liegts wohl an was anderem und der Test macht keinen Sinn. Letzte Idee könnte irgendwo im Power Management liegen, würde mal versuchen alles zu disablen (insbesondere auf dem PCI Bus und das Device selbst), hab aber keine Ahnung wo die Schalter sind.

  • ...Letzte Idee könnte irgendwo im Power Management liegen, würde mal versuchen alles zu disablen (insbesondere auf dem PCI Bus und das Device selbst), hab aber keine Ahnung wo die Schalter sind.


    Gute Idee - vielen Dank. Das könnte erklären, warum es "irgendwann" passiert. Vielleicht bei einer CPU-Drosselung oder ähnlichem. Werde ich probieren.


    Ich habe jetzt zusätzlich das Paket vdr-debuginfo installiert und vor dem Start des VDR den Befehl "ulimit -c unlimited" ausgeführt, wie u.a. hier und hier beschrieben. Keine Ahnung, ob es was bringt - ich lasse mich überraschen...


    Euch beiden erst einmal vielen Dank!

  • ...zusätzlich das Paket vdr-debuginfo installiert und vor dem Start des VDR den Befehl "ulimit -c unlimited" ausgeführt...


    Tja - das ging jetzt schneller als erwartet. Start um 23:14, Absturz um 23:32. Hier die letzten Log-Einträge:


    Leider auch mit den genannten Debug-Optionen (so man sie denn überhaupt so bezeichnen kann) nicht ergiebiger. Bin mir auch nicht sicher, ob ich da korrekt debuggt habe. Denn eine (wie hier genannte) /tmp/core.2841 oder ansatzweise ähnliches ist weder im /tmp- Verzeichnis, noch im zum Zeitpunkt der Befehlsausfühung befindlichen Verzeichnis, noch im /root-Verzeichnis vorhanden.


    Es muss doch möglich sein, durch irgendeine Ausgabe dem Fehler auf die Schliche zu kommen...


    Ich mache Schluss :sleep -- weitere Ideen sind willkommen :-)

  • Ihr habt einen kleinen Denkfehler bei dem Test in der Dom0:
    Die Dom0 ist nicht ohne Virtualisierung. Die Dom0 ist nur eine privilegierte VM. Der Xen Kernel ist trotzdem aktiv und es läuft alles über Xen. Auch wenn die Dom0 die echte Hardware sehen kann.


    Also boote den Rechner bitte einmal komplett ohne den Xen-kernel. Normalweise gibt es dafür einen Eintrag im Bootmenü.
    Dann mache den Versuch nochmal.

  • Also boote den Rechner bitte einmal komplett ohne den Xen-kernel. Normalweise gibt es dafür einen Eintrag im Bootmenü. Dann mache den Versuch nochmal.


    Wieder etwas dazugelernt - besten Dank für den Tipp. Gebracht hat es aber leider nichts. Auch mit dem Desktop-Kernel (vmlinuz-3.11.10-21-desktop / OpenSuse 13.1) friert das System nach Start des VDR ein. Diesmal hat es 31 Minuten gedauert:


    wirbel : Du hattest das Thema in "Linux > Server" verschoben. Da wir jetzt wissen, dass es nicht an der Virtualisierungsschicht liegt: Macht es nicht Sinn, das Thema wieder zurück in "Hardware > DVB-Karten" zu schieben?

  • Ich bin im vdr-portal kein Moderator. ;)