[gelöst] Cine S2 V6.5 mit Proxmox 4.2 / nach mehrmaligen restarts der VM sporadisch kein TV mehr möglich / Host muss neu gestartet werden

  • Hallo Leute,


    nachdem ich glücklich die DVB Sky Karte verlassen hatte und zur CineS2 V6.5 gewechselt hatte, stellt sich mir leider doch noch ein ähnliches Problem das ich mit der DVB Sky auch hatte. Bei der DVB Sky musste ich wenn der VDRdienst neu gestartet wurde die VM ausschalten und wieder starten. Tat ich das nicht waren 2Cores immer auf 100% und vdr-live funktionierte nicht mehr. Das kam sporadisch alle paar Wochen mal vor. Aber auch ohne Zutun manchmal mehrmals am Tag. Dort war die Karte defekt.


    Das Problem habe ich jetzt zum Glück so nicht mehr. Ich kann die VM starten läuft alles super. Die Uptime jetzt war glaub ich ca. einen Monat. Jetzt am Wochenende hatte ich VM mehrmals durchgestartet, da ich ein externes Backup machte, das mache ich jedes halbe Jahr mal. Heute wollte ich gucken und der VNSI meinte "no data". Ein neu Starten oder auch stoppen starten der VM brachte keinen Erfolg. Es sah alles normal aus. Alle Dienste laufen, Empfang ist das. Es kommen nur einfach keine Daten. Ein Reboot der ganzen Hostmaschine hat dann geholfen.


    Nachtrag: Manchmal muss die Hostmaschine ausgeschalten werden, erst dann geht die VDR-VM wieder. Ich würde es ja gerne am Host testen wenns in der VM nicht funktioniert. Ist aber nicht mögliche, müsste das Mediabuild einspielen. Hab so das Gefühl das es am Host gehen würde... oder ich hab tatsächlich ne defekte VDRkarte geliefert bekommen, was ich ja nicht glaube aber wohl nicht unmöglich ist.


    Hier mal die aktuelle Systeminfo des Hosts.


    proxmox-ve: 4.2-56 (running kernel: 4.4.13-1-pve)
    pve-manager: 4.2-15 (running version: 4.2-15/6669ad2c)
    pve-kernel-4.4.13-1-pve: 4.4.13-56
    pve-kernel-4.4.10-1-pve: 4.4.10-54
    lvm2: 2.02.116-pve2
    corosync-pve: 2.3.5-2
    libqb0: 1.0-1
    pve-cluster: 4.0-42
    qemu-server: 4.0-83
    pve-firmware: 1.1-8
    libpve-common-perl: 4.0-70
    libpve-access-control: 4.0-16
    libpve-storage-perl: 4.0-55
    pve-libspice-server1: 0.12.5-2
    vncterm: 1.2-1
    pve-qemu-kvm: 2.5-19
    pve-container: 1.0-70
    pve-firewall: 2.0-29
    pve-ha-manager: 1.0-32
    ksm-control-daemon: 1.2-1
    glusterfs-client: 3.5.2-2+deb8u2
    lxc-pve: 1.1.5-7
    lxcfs: 2.0.0-pve2
    cgmanager: 0.39-pve1
    criu: 1.6.0-1
    zfsutils: 0.6.5.7-pve10~bpo80


    Ich habe auch sämtliche Module die für die Karte zuständig sind beim host in eine Blacklist getan. Sollte also auch passen.
    /etc/modprobe.d/fbdev-blacklist.conf

    blacklist cx23885
    # für V3
    blacklist rc_dvbsky
    blacklist m88ds3103
    blacklist smipcie
    blacklist dvb_core
    # für CineS2
    blacklist ddbridge
    blacklist stv090x
    blacklist lnbp21
    blacklist stv6110x


    Die VM ist ein Gentoo mit den DDbridge Sources 4.6.2-ddbridge. Ich glaub aber nicht das es was der VM direkt zu tun hat, da ja ein Neustart dieser hier nichts bewirkt.


    Die Frage die sich mich jetzt stellt, hat so ein Verhalten sonst auch noch wer, oder woran könnte es überhaupt liegen?


    Vielen Dank und lg

    System: Gentoo VDR auf Proxmox virtualisiert im LXC
    Digital Devices Cine S2 V6.5

    Kodi 18.x mit VNSi

    The post was edited 2 times, last by looking111 ().

  • Musste zwischendurch schon wieder 2mal Ausschalten. Event. beißt sich was mit einem Kernelmodul vom Hostsystem. Ich habe aber nichts verdächtiges enteckt. Im Anhang lsmod vom Proxmoxhost. Vielleicht findet ja von euch da wer was an.


    lg

    Files

    System: Gentoo VDR auf Proxmox virtualisiert im LXC
    Digital Devices Cine S2 V6.5

    Kodi 18.x mit VNSi


  • Moinsen, ich beschäftige mich derzeitig auch mit der Virtualisierung von
    VDR und anderen Diensten. Als Host-System benutze ich die aktuelle Version proxmox. Bin aber derzeitig noch am probieren, da das ganze PCI-Passthrough-Zeugs für mich Neuland ist. Ich hatte es in der Vergangenheit irgendwann schonmal probiert, aber es gab einige Bugs, so dass ich mich dann damals (vor. ca 5Jahren) doch wieder gegen die Virtualisierung entschieden habe.


    Ich habe mal eine Frage bzw. Anmerkung zu deiner blacklist. Bei mir sieht das auf der Konsole wie folgt aus:



    ddbridge lädt bei mir 3 Module, in deiner blacklist sehe ich allerdings nur ddbridge. cxd2099 und dvb_core fehlen bei dir. Hat das einen Grund?


    Wofür sind die in anderen 3 in deiner Blacklist aufgeführten Module zuständig? Was haben die mit der Cine S2 zu tun? Bei mir werden diese Module auf dem Hostsystem auch standardmäßig geladen. Ich nehme an, dass es sich bei der V3 um eine andere TV-Karte handelt? Die Module werden bei mir nicht geladen?


    Hast du deine Probleme ggf. mittlerweile in den Griff bekommen?


    Viele Grüße Hoppel

    frontend software - android tv | libreelec | windows 10 | kodi krypton | emby for kodi | vnsi
    frontend hardware - nvidia shield tv | odroid c2 | yamaha rx-a1020 | quadral chromium style 5.1 | samsung le40-a789r2 | harmony smart control
    -------------------------------------------
    backend software - proxmox | openmediavault | debian jessie | kernel 4.4lts | zfs | emby | vdr | vnsi | fhem
    backend hardware - supermicro x11ssh-ctf | xeon E3-1240L-v5 | 64gb ecc | 8x4tb wd red | raid-z2 | digital devices max s8

    The post was edited 1 time, last by hoppel118 ().

  • Servus,


    konkret zu Deinem Problem kann ich nix sagen, aber der Reboot der VM und/oder des Hosts kann evtl. vermieden werden, wenn Du nur die Cine einen Reset machen lässt. Ich habe das hier beschrieben. Die Probleme, dass die Karte nicht mehr reagiert, hatte ich aber seitdem auch nicht mehr. Da es ja nur sporadisch war, kann ich nicht sagen, ob der Kernel-Downgrade oder der Upgrade auf einen neue Proxmox-Version damals die Aussetzer behoben hat. Aber da Du das ja jetzt mit der aktuellen Version hast...


    Blacklist habe ich keine angelegt, lediglich eine "iommu_unsafe_interrupts.conf" mit Inhalt "options vfio_iommu_type1 allow_unsafe_interrupts=1" angelegt, weil ich ein paar Kernel-Panics auf dem Host hatte. Module für die DD sind auf dem Host geladen, stören aber nicht, die Karte funktioniert seit langer Zeit einwandfrei in der VM mit MiniDVBLinux.


    cu
    Markus

  • Hallo Mahlzeit,


    danke für die Info. Das man die Module blacklisten soll, steht auch gar nicht im proxmox-wiki unter "PCI EXPRESS PASSTHROUGH". Habe es allerdings auch öfters irgendwo im Internet gelesen, dass man die Module blacklisten soll. Von daher ist es umso besser, dass du deine Erfahrungen hier teilst. Ich werde die Module auf dem Host also nicht blacklisten.


    Ich habe mittlerweile eine Sata-SSD, einen LSI3008-SAS-Controller und die Cine-S2-TV-Karte an meine VM durchgereicht, zumindest sehe ich die devices nun in der VM (openmediavault). Vorher hatte ich openmediavault und alle Dienste direkt auf dem Blech bzw. dem zugrunde liegenden debian installiert. Erstmal möchte ich so wenig Abweichungen zur vorherigen Umgebung wie möglich, damit ich im Fehlerfall besser eingrenzen kann. Bevor ich mit dem ganzen LXC-Kram herumspiele, möchte ich also meine gesamte config in dieser einen VM zum Laufen bekommen. Später kann ich mir dann immer noch überlegen, was ich genau wie verteile und ggf. neu aufsetze und evtl. zusätzlich als Testsystem aufsetze.


    Eine Sache ist mir gerade bezüglich der Cine S2 aufgefallen:


    Auf dem Host sind folgende Module geladen:


    Code
    1. root@proxmox:~# lsmod | grep ddbridge
    2. ddbridge 24576 0
    3. cxd2099 20480 1 ddbridge
    4. dvb_core 122880 1 ddbridge


    In der VM folgende Module:


    Code
    1. root@mediatank:~# lsmod | grep ddbridge
    2. ddbridge 21641 0
    3. dvb_core 102010 1 ddbridge
    4. i2c_core 46012 4 drm,i2c_i801,ddbridge,drm_kms_helper


    Hast du dazu eine Idee? Warum werden in der VM andere Module geladen als auf dem Host? Hängt das evtl. mit den unterschiedlichen Kernel zusammen? Proxmox läuft mit "4.4.19-1-pve" und openmediavault mit "3.16.0-4-amd64". Ich werde mir unter openmediavault mal einen aktuelleren Kernel aus den Backports ziehen.


    Im nächsten Schritt werde ich dann erstmal openmediavault und meine Dienste einrichten. Habe aber momentan wenig Zeit. Mal sehen, wie es hier weiter geht.



    Gruß Hoppel

    frontend software - android tv | libreelec | windows 10 | kodi krypton | emby for kodi | vnsi
    frontend hardware - nvidia shield tv | odroid c2 | yamaha rx-a1020 | quadral chromium style 5.1 | samsung le40-a789r2 | harmony smart control
    -------------------------------------------
    backend software - proxmox | openmediavault | debian jessie | kernel 4.4lts | zfs | emby | vdr | vnsi | fhem
    backend hardware - supermicro x11ssh-ctf | xeon E3-1240L-v5 | 64gb ecc | 8x4tb wd red | raid-z2 | digital devices max s8

    The post was edited 3 times, last by hoppel118 ().

  • Servus Hoppel,


    die unterschiedlichen Module hätte ich spontan auch den verschiedenen Kernelversionen zugeordnet.


    cu
    Mahlzeit

  • Danke für Meldung hier, bin mittlerweile draufgekommen das es tatsächlich mit der Virtualisierung nicht astrein lief. Muss wohl alles zu 100% genau passen. Ist wohl auch ein wenig eine Glückssache das die HW passt (Bios Version usw.). Hab nun auf PHY zurück gestellt und alles läuft mit exakt dem selben System (hab die VM runter auf PHY kopiert) wieder supi!
    [gelöst] VDR DVB-Device Standby, ist das Default, oder wie sieht das den aus bei vdr 2.2?



    lg

    System: Gentoo VDR auf Proxmox virtualisiert im LXC
    Digital Devices Cine S2 V6.5

    Kodi 18.x mit VNSi

  • looking111 Was für Hardware hast du eigentlich im Einsatz (Mainboard-Hersteller/-Modell, CPU, etc.), wenn ich fragen darf?

    frontend software - android tv | libreelec | windows 10 | kodi krypton | emby for kodi | vnsi
    frontend hardware - nvidia shield tv | odroid c2 | yamaha rx-a1020 | quadral chromium style 5.1 | samsung le40-a789r2 | harmony smart control
    -------------------------------------------
    backend software - proxmox | openmediavault | debian jessie | kernel 4.4lts | zfs | emby | vdr | vnsi | fhem
    backend hardware - supermicro x11ssh-ctf | xeon E3-1240L-v5 | 64gb ecc | 8x4tb wd red | raid-z2 | digital devices max s8

  • Virtualisiert hatte ich es auf Supermicro
    ProductX10SAE
    Intel(R) Xeon(R) CPU E3-1265L v3 @ 2.50GHz
    ZFS Raid10 SSD Cache


    Jetzt läuft es für's erste auf:
    VendorFUJITSU // Phoenix Technologies Ltd.
    Version6.00 Rev. 1.13.2799.N1
    ModelIntel(R) Xeon(R) CPU E5620 @ 2.40GHz
    HW Raid15K Raid10


    Wird aber dann Final ein Supermicro IDX Board mit i3 und 2 SSDs im Raid1 werden. Ist ja für nativ genug an Power.

    System: Gentoo VDR auf Proxmox virtualisiert im LXC
    Digital Devices Cine S2 V6.5

    Kodi 18.x mit VNSi

  • Na dann bin ich ja mal gespannt, ob das irgendwann mit meinem Supermicro X11SSH-CTF stabil läuft...


    Habe auch noch ein anderes Problem mit der Digital Devices Max S8 in Kombination mit dem Supermicro-Mainboard. Hatte dazu auch schon Kontakt mit Digital Devices. Sehr guter und freundlicher Support. Man hat sich für mein Anliegen wirklich viel Zeit genommen. Ein paar Dinge möchte ich allerdings selbst noch testen, bevor ich das Thema gänzlich aufgebe. Das wird jedoch sehr zeitaufwendig und passt momentan einfach überhaupt nicht rein. Naja, Herbst und Winter stehen ja schon wieder vor der Tür. Wenn's draußen dunkel und ungemütlich wird, werde ich die Zeit finden. ;)


    Danke für die Info! Gruß Hoppel

    frontend software - android tv | libreelec | windows 10 | kodi krypton | emby for kodi | vnsi
    frontend hardware - nvidia shield tv | odroid c2 | yamaha rx-a1020 | quadral chromium style 5.1 | samsung le40-a789r2 | harmony smart control
    -------------------------------------------
    backend software - proxmox | openmediavault | debian jessie | kernel 4.4lts | zfs | emby | vdr | vnsi | fhem
    backend hardware - supermicro x11ssh-ctf | xeon E3-1240L-v5 | 64gb ecc | 8x4tb wd red | raid-z2 | digital devices max s8

  • Ich meine erstmal gar nichts, so lange ich es nicht selbst getestet habe.


    Die Digital Devices Max S8 habe ich auf meinem Supermicro-Mainboard bisher noch nicht zum Laufen bekommen. Die Karte wird einfach gar nicht erkannt, kein Eintrag unter lspci. Beim Booten kann man direkt nach dem Einschalten an den LEDs der Max S8 erkennen, dass irgendwas nicht korrekt ausgehandelt werden kann. Es liegt aber am Supermicro-Mainboard, da diese Karte in Kombination mit einem Asus-Mainboard sofort erkannt wird.


    Die Digital Devices Cine S2 v6.5 hingegen läuft mit dem Supermicro-Mainboard ohne Virtualisierung absolut stabil und das sogar mit dem Treiber der im Kernel (4.4 habe ich mir aus den Backports gezogen) bereits enthalten ist, also plug-n-play. An den PCIE-Port-Settings im Mainboard-BIOS musste ich bei meiner Konstellation für die Cine S2 v6.5 nichts angepassen. Wie es mit dem Supermicro X11SSH-CTF, der Cine S2 v6.5 und Virtualisierung in Kombination aussieht, muss ich erst noch testen. ;)


    Bye

    frontend software - android tv | libreelec | windows 10 | kodi krypton | emby for kodi | vnsi
    frontend hardware - nvidia shield tv | odroid c2 | yamaha rx-a1020 | quadral chromium style 5.1 | samsung le40-a789r2 | harmony smart control
    -------------------------------------------
    backend software - proxmox | openmediavault | debian jessie | kernel 4.4lts | zfs | emby | vdr | vnsi | fhem
    backend hardware - supermicro x11ssh-ctf | xeon E3-1240L-v5 | 64gb ecc | 8x4tb wd red | raid-z2 | digital devices max s8

  • bil und das sogar mit dem Treiber der im Kernel (4.4 habe ich mir aus den Backports gezogen) bereits enthalten ist, also plug-n-play. An den PCIE-Port-Settings im Mainboard-BIOS musste ich bei meiner Konstellation für die Cine S2 v6.5 nichts angepassen. Wie es mit dem Supermicro X11SSH-CTF, der Cine S2 v6.5 und Virtualisierung in Kombination aussieht, muss ich erst noch testen. ;)


    Bye


    Ich habe ein Supermicro X10SLM+-LN4F Board, die Cine S2 v6.5 im ESXI 5.5 betrieben und nur Stress und Ärger gehabt mit Timeouts. auch mit msi=0 in ddbridge.


    Jetzt versuche ich erst mal die Karte auf einem anderen Supermicro Board einzubinden ohne ESXI....viel GLück :D

  • die unterschiedlichen Module hätte ich spontan auch den verschiedenen Kernelversionen zugeordnet.


    Ich habe übrigens den kernel und die headers 4.4.19-1 des Hostsystems in der kvm installiert. Nun werden dieselben Module geladen, wie auf dem Host. Das gefällt mir optisch schonmla gut. Aber auch grundsätzlich stimmt mich das erstmal positiv ein. Nun kann ich bald mit der Konfiguration der einzelnen Dienste beginnen. ;)

    frontend software - android tv | libreelec | windows 10 | kodi krypton | emby for kodi | vnsi
    frontend hardware - nvidia shield tv | odroid c2 | yamaha rx-a1020 | quadral chromium style 5.1 | samsung le40-a789r2 | harmony smart control
    -------------------------------------------
    backend software - proxmox | openmediavault | debian jessie | kernel 4.4lts | zfs | emby | vdr | vnsi | fhem
    backend hardware - supermicro x11ssh-ctf | xeon E3-1240L-v5 | 64gb ecc | 8x4tb wd red | raid-z2 | digital devices max s8

  • Quote

    Ich habe ein Supermicro X10SLM+-LN4F Board, die Cine S2 v6.5 im ESXI 5.5 betrieben und nur Stress und Ärger gehabt mit Timeouts. auch mit msi=0 in ddbridge.


    Jetzt versuche ich erst mal die Karte auf einem anderen Supermicro Board einzubinden ohne ESXI....viel GLück :D


    So, nach ein paar Tagen Betrieb kann ich erstmal nichts negatives berichten. Meintest du mit Timeouts eigentlich folgende Meldungen im Syslog?





    Ich hatte vergessen, dass ich Anfang des Jahres, als ich openmediavault direkt auf dem Blech installiert hatte, auch schonmal Timeout-Probleme hatte. Diese Timeout-Probleme waren für mich aber
    damals nicht spürbar. Sie erschienen lediglich in meinen Logfiles bzw. sie haben mein Logfile zugemüllt. Ich hatte dazu damals auch einen Thread im OMV-Forum:


    http://forum.openmediavault.or…d-error-received-id-00e0/


    Damals habe ich dieses Problem wie im Link geschildet mit den Bootoptionen "pci=nomsi,noaer" in den Griff bekommen. Heute, wo seit ca. einer Woche Proxmox auf dem Blech läuft, sind mir diese Meldungen plötzlich wieder aufgefallen. Ich habe das Thema diesmal anscheind mit "pci=noaer" in der "/etc/default/grub" in den Griff bekommen. Wenn ich "pci=nomsi,noaer" setze, wird mein SAS-Controller nicht mehr in der kvm erkannt. ;)



    Nach der grub-Konfiguration und dem ersten Reboot hatte ich dann folgende Meldungen im Syslog:


    Code
    1. root@proxmox:~# dmesg | grep pcieport
    2. Oct 6 01:45:36 proxmox kernel: [ 0.947765] pcieport 0000:00:01.0: Signaling PME through PCIe PME interrupt
    3. Oct 6 01:45:36 proxmox kernel: [ 0.947795] pcieport 0000:00:1c.0: Signaling PME through PCIe PME interrupt
    4. Oct 6 01:45:36 proxmox kernel: [ 0.947817] pcieport 0000:00:1c.2: Signaling PME through PCIe PME interrupt
    5. Oct 6 01:45:36 proxmox kernel: [ 0.947841] pcieport 0000:00:1c.4: Signaling PME through PCIe PME interrupt


    Das sieht schonmal wesentlich besser aus. Na schauen wir morgen mal, ob es weitere oder überhaupt neue Meldungen im Syslog gibt.


    Viele Grüße Hoppel

    frontend software - android tv | libreelec | windows 10 | kodi krypton | emby for kodi | vnsi
    frontend hardware - nvidia shield tv | odroid c2 | yamaha rx-a1020 | quadral chromium style 5.1 | samsung le40-a789r2 | harmony smart control
    -------------------------------------------
    backend software - proxmox | openmediavault | debian jessie | kernel 4.4lts | zfs | emby | vdr | vnsi | fhem
    backend hardware - supermicro x11ssh-ctf | xeon E3-1240L-v5 | 64gb ecc | 8x4tb wd red | raid-z2 | digital devices max s8

    The post was edited 1 time, last by hoppel118 ().

  • Die oben genannten Timeout-Meldungen erscheinen nun nicht mehr. :D

    frontend software - android tv | libreelec | windows 10 | kodi krypton | emby for kodi | vnsi
    frontend hardware - nvidia shield tv | odroid c2 | yamaha rx-a1020 | quadral chromium style 5.1 | samsung le40-a789r2 | harmony smart control
    -------------------------------------------
    backend software - proxmox | openmediavault | debian jessie | kernel 4.4lts | zfs | emby | vdr | vnsi | fhem
    backend hardware - supermicro x11ssh-ctf | xeon E3-1240L-v5 | 64gb ecc | 8x4tb wd red | raid-z2 | digital devices max s8

  • Moinsen,

    Ich habe ein Supermicro X10SLM+-LN4F Board, die Cine S2 v6.5 im ESXI 5.5 betrieben und nur Stress und Ärger gehabt mit Timeouts. auch mit msi=0 in ddbridge.


    Jetzt versuche ich erst mal die Karte auf einem anderen Supermicro Board einzubinden ohne ESXI....viel GLück :D

    ich habe die kvm nun mittlerweile fast 2 Wochen am Laufen. Bisher gab es keine Timeoutmeldungen oder sonstige Spinnereien bei meinem VDR. Der lüppt einfach (auch wenn der Server bisher noch nicht die Chance hatte ohne Reboot durchzulaufen, weil ich gerade noch ein ein anderes Thema mit dem Spindown meiner 8x4TB in Kombination mit zfs habe...) Ich habe die Cine S2 im Hostsystem nicht geblacklisted, sondern einfach nur wie folgt durchgereicht.


    Code
    1. root@proxmox:~# nano /etc/pve/qemu-server/vmid.conf
    2. ...
    3. machine: q35
    4. hostpci1: 02:00.0,pcie=1
    5. ...



    Gruß Hoppel

    frontend software - android tv | libreelec | windows 10 | kodi krypton | emby for kodi | vnsi
    frontend hardware - nvidia shield tv | odroid c2 | yamaha rx-a1020 | quadral chromium style 5.1 | samsung le40-a789r2 | harmony smart control
    -------------------------------------------
    backend software - proxmox | openmediavault | debian jessie | kernel 4.4lts | zfs | emby | vdr | vnsi | fhem
    backend hardware - supermicro x11ssh-ctf | xeon E3-1240L-v5 | 64gb ecc | 8x4tb wd red | raid-z2 | digital devices max s8

    The post was edited 1 time, last by hoppel118 ().

  • Moinsen,


    wo ich denThread hier gerade wieder finde... Zur Info, meine cine s2 v6.5 läuft seither (mittlerweile knappe 5 Monate) in meiner KVM absolut stabil. VDR mit VNSI und Kodi PVR läuft einfach tiptop!


    Dennoch habe ich kürzlich meinen Host und alle meine virtuellen Maschinen neu aufgesetzt. Irgendwie habe ich damals nicht ganz so clevere Design-Entscheidungen getroffen. Naja, Versuch macht "kluch". ;)


    Die AER-Timeouts hatte ich jetzt übrigens nicht mehr. Da ich letzte Woche Proxmox in der aktuellsten Version aufgesetzt habe und kurz vorher ein BIOS-Update für mein Mainboard-BIOS installiert habe, kann ich nicht sagen, was das Problem nun genau gelöst hat. Auf jeden Fall habe ich diesmal keine zusätzlichen Bootoptionen in grub konfiguriert.



    Viele Grüße Hoppel

    frontend software - android tv | libreelec | windows 10 | kodi krypton | emby for kodi | vnsi
    frontend hardware - nvidia shield tv | odroid c2 | yamaha rx-a1020 | quadral chromium style 5.1 | samsung le40-a789r2 | harmony smart control
    -------------------------------------------
    backend software - proxmox | openmediavault | debian jessie | kernel 4.4lts | zfs | emby | vdr | vnsi | fhem
    backend hardware - supermicro x11ssh-ctf | xeon E3-1240L-v5 | 64gb ecc | 8x4tb wd red | raid-z2 | digital devices max s8

  • Was habt ihr denn besonderes gemacht? Ich kriege meine beiden cineS2 partout nicht unter Proxmox 5.1 in einer KVM-VM zum rennen, auch nicht solo ...


    [ 2.588341] nGene PCIE bridge driver, Copyright (C) 2005-2007 Micronas

    [ 2.588664] ngene: Found Linux4Media cineS2 DVB-S2 Twin Tuner

    [ 2.591147] ngene: Device version 1


    so weit so gut, aber dann


    [ 4.596116] ngene: Command timeout cmd=01 prev=00

    [ 4.596168] host_to_ngene (c000): 01 00 00 00 00 00 00 00

    [ 4.596218] ngene_to_host (c100): 00 00 00 00 00 00 00 00

    [ 4.596249] dev->hosttongene (ffff88003adef000): 01 00 00 00 00 00 00 00

    [ 4.596289] dev->ngenetohost (ffff88003adef100): 00 00 00 00 00 00 00 00

    [ 6.608113] ngene: Command timeout cmd=02 prev=00

    [ 6.608166] host_to_ngene (c000): 02 04 00 d0 00 04 00 00

    [ 6.608214] ngene_to_host (c100): 00 00 00 00 00 00 00 00

    [ 6.608245] dev->hosttongene (ffff88003adef000): 02 04 00 d0 00 04 00 00

    [ 6.608285] dev->ngenetohost (ffff88003adef100): 00 00 00 00 00 00 00 00

    [ 6.610923] ngene: probe of 0000:01:00.0 failed with error -1


    Auf dem selben Rechner mit ESXi 6.5 (und davor auch mit 5.5) klappt das (mit derselben yaVDR Installation) super ...