[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

Quote from looking111

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

Display More

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:

root@proxmox:~# lsmod | grep ddbridge
ddbridge               24576  0
cxd2099                20480  1 ddbridge
dvb_core              122880  1 ddbridge
root@proxmox:~# lsmod | grep stv090x
stv090x                73728  2
root@proxmox:~# lsmod | grep lnbp21
lnbp21                 16384  2
root@proxmox:~# lsmod | grep stv6110x
stv6110x               16384  2
root@proxmox:~# lsmod | grep rc_dvbsky
root@proxmox:~# lsmod | grep m88ds3103
root@proxmox:~# lsmod | grep smipcie

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

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:

root@proxmox:~# lsmod | grep ddbridge
ddbridge               24576  0
cxd2099                20480  1 ddbridge
dvb_core              122880  1 ddbridge

In der VM folgende Module:

root@mediatank:~# lsmod | grep ddbridge
ddbridge               21641  0
dvb_core              102010  1 ddbridge
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

Servus Hoppel,

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

cu
Mahlzeit

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

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

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

Quote from hoppel118

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

Quote from mahlzeit

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.

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

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

root@proxmox:~# cat /var/log/syslog | grep pcieport
Oct  5 23:06:45 proxmox kernel: [271601.881062] pcieport 0000:00:1c.0: AER: Corrected error received: id=00e0
Oct  5 23:06:45 proxmox kernel: [271601.881071] pcieport 0000:00:1c.0: PCIe Bus Error: severity=Corrected, type=Data Link Layer, id=00e0(Transmitter ID)
Oct  5 23:06:45 proxmox kernel: [271601.881931] pcieport 0000:00:1c.0:   device [8086:a110] error status/mask=00001000/00002000
Oct  5 23:06:45 proxmox kernel: [271601.882718] pcieport 0000:00:1c.0:	[12] Replay Timer Timeout
Oct  5 23:24:18 proxmox kernel: [272655.011201] pcieport 0000:00:1c.0: AER: Corrected error received: id=00e0
Oct  5 23:24:18 proxmox kernel: [272655.011208] pcieport 0000:00:1c.0: PCIe Bus Error: severity=Corrected, type=Data Link Layer, id=00e0(Transmitter ID)
Oct  5 23:24:18 proxmox kernel: [272655.012125] pcieport 0000:00:1c.0:   device [8086:a110] error status/mask=00001000/00002000
Oct  5 23:24:18 proxmox kernel: [272655.013206] pcieport 0000:00:1c.0:	[12] Replay Timer Timeout
Oct  6 00:03:20 proxmox kernel: [274996.287774] pcieport 0000:00:1c.0: AER: Corrected error received: id=00e0
Oct  6 00:03:20 proxmox kernel: [274996.287790] pcieport 0000:00:1c.0: PCIe Bus Error: severity=Corrected, type=Data Link Layer, id=00e0(Transmitter ID)
Oct  6 00:03:20 proxmox kernel: [274996.288676] pcieport 0000:00:1c.0:   device [8086:a110] error status/mask=00001000/00002000
Oct  6 00:03:20 proxmox kernel: [274996.289759] pcieport 0000:00:1c.0:	[12] Replay Timer Timeout
Oct  6 00:53:57 proxmox kernel: [278033.565945] pcieport 0000:00:1c.0: AER: Corrected error received: id=00e0
Oct  6 00:53:57 proxmox kernel: [278033.565955] pcieport 0000:00:1c.0: PCIe Bus Error: severity=Corrected, type=Data Link Layer, id=00e0(Transmitter ID)
Oct  6 00:53:57 proxmox kernel: [278033.566847] pcieport 0000:00:1c.0:   device [8086:a110] error status/mask=00001000/00002000
Oct  6 00:53:57 proxmox kernel: [278033.567833] pcieport 0000:00:1c.0:	[12] Replay Timer Timeout

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.org/index.php/Thre…ceived-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:

root@proxmox:~# dmesg | grep pcieport
Oct  6 01:45:36 proxmox kernel: [	0.947765] pcieport 0000:00:01.0: Signaling PME through PCIe PME interrupt
Oct  6 01:45:36 proxmox kernel: [	0.947795] pcieport 0000:00:1c.0: Signaling PME through PCIe PME interrupt
Oct  6 01:45:36 proxmox kernel: [	0.947817] pcieport 0000:00:1c.2: Signaling PME through PCIe PME interrupt
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

Die oben genannten Timeout-Meldungen erscheinen nun nicht mehr.

Moinsen,

Quote from brooks

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

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.

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

Gruß Hoppel

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

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 ...