Treiber der Cine-CTv6/DDBridge/CI in den Kernel integrieren

  • Da freut man sich so auf 4.14, dass man nicht mehr soviel frickeln muss und nun sowas 8o


    "kmod-staging" scheint es nicht mehr zu geben bei RPMFusion.

    Tja. Gegen die (IMHO äusserst seltsamen, speziell im RPM-Bereich) Launen der Binärdistributoren helfen alle Anstrengungen rund um den Upstream nix :rolleyes: Aber auch an diesem Problem (cxd2099 in staging) wird bereits gearbeitet...

    Server: Gigabyte P35-DS4, Intel Core2Duo E6850, 4GB DDR2-RAM (Headless), Gentoo Linux x86_64 / Kernel 4.13.9 / DD CineCTv6+DuoFlex C/T/T2+DuoFlex C/C2/T/T2 w/Kernel Stock Drivers / TVHeadend-GIT-3356759d8

    HTPC: Gigabyte GA-EG41MF-US2H, Intel Core2Duo E7500, 2GB DDR2-RAM, NVIDIA GT610/1GB PCIe in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 )
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VDPAU+HD-Audio+LCDproc addon / Ubuntu Trusty 14.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

  • gestern war offenbar mal wieder "Merge-Day" im media_tree, dabei wurden die ddbridge-0.9.32 Patches mitgemerged. Die Changes werden in Linux-4.16(rc1) landen. Einen wirklichen Grund, darauf zu warten, gibts aber eigentlich nicht, dddvb-0.9.31->0.9.32 war im Tunerkartenbereich nur 'ne Aufräumaktion.


    Moinsen,


    bin kürzlich mit meinem Openmediavault System auf Debian Stretch (Openmediavault4) umgestiegen. Ich hatte es nun eigentlich so in Erinnerung, dass meine Max S8 ab Kernel 4.14 out-of-the-box läuft. Ist das jetzt noch so?


    In den Backports von Debian Stretch gibt es seit gestern nämlich folgende Pakete:

    • linux-image-4.14.0-0.bpo.2-amd64 - Linux 4.14 for 64-bit PCs
    • linux-headers-4.14.0-0.bpo.2-amd64 - Header files for Linux 4.14.0-0.bpo.2-amd64
    • linux-kbuild-4.14 - Kbuild infrastructure for Linux 4.14

    Falls das damit nicht funktioniert, wäre ich euch dankbar, wenn mir einer die entsprechenden Befehle kurz aufschlüsseln könnte, um den richtigen Treiber selbst zu bauen.


    Folgende Kernel habe ich derzeitig in Stretch zur Auswahl:

    • linux-image-4.9.0-5-amd64 - Linux 4.9 for 64-bit PCs
    • linux-image-4.13.0-0.bpo.1-amd64 - Linux 4.13 for 64-bit PCs
    • linux-image-4.14.0-0.bpo.2-amd64 - Linux 4.14 for 64-bit PCs

    Welchen Kernel würdet ihr mir dann für den selbst zu bauenden Kernel empfehlen?


    Derzeitig habe ich Kernel 4.9 im Einsatz, da ich auf der gleichen Maschine auch noch ein ZFS betreibe und ich mir unsicher bin, ob das mit den neueren Kerneln schon funktioniert.


    Danke euch schonmal und 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 hatte es nun eigentlich so in Erinnerung, dass meine Max S8 ab Kernel 4.14 out-of-the-box läuft. Ist das jetzt noch so?

    Yep.


    In den Backports von Debian Stretch gibt es seit gestern nämlich folgende Pakete:

    • linux-image-4.14.0-0.bpo.2-amd64 - Linux 4.14 for 64-bit PCs
    • linux-headers-4.14.0-0.bpo.2-amd64 - Header files for Linux 4.14.0-0.bpo.2-amd64
    • linux-kbuild-4.14 - Kbuild infrastructure for Linux 4.14

    Wenn die Debian-Herrschaften nicht irgendwelchen Unsinn paketieren (ich schreib das ganz bewusst, weil z.B. die RPM/Fedora-Herrschaften keine Staging-Module paketieren und deshalb die CXD2099AR-basierten CI-Flexmodule nicht funktionieren) solltest Du damit glücklich werden.

    Server: Gigabyte P35-DS4, Intel Core2Duo E6850, 4GB DDR2-RAM (Headless), Gentoo Linux x86_64 / Kernel 4.13.9 / DD CineCTv6+DuoFlex C/T/T2+DuoFlex C/C2/T/T2 w/Kernel Stock Drivers / TVHeadend-GIT-3356759d8

    HTPC: Gigabyte GA-EG41MF-US2H, Intel Core2Duo E7500, 2GB DDR2-RAM, NVIDIA GT610/1GB PCIe in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 )
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VDPAU+HD-Audio+LCDproc addon / Ubuntu Trusty 14.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

  • Naja, was spricht dagegen einfach mal den 4.14er Kernel zu testen ... geht doch nix kaputt ...

    HowTo: APT pinning

  • So, hatte gerade Zeit mich damit zu beschäftigen. Mein ZFS-Pool und meine Max S8 laufen beide mit Kernel 4.14. Das war gar nicht so schwer.


    Ich bin wie folgt vorgegangen:


    1. Installation der 4.14 Kernel Pakete aus den Debian Stretch Backports

    2. Reboot und booten des neuen Kernels

    3. Prüfen, was Sache ist:


    a. Welcher Kernel wurde gebootet?

    Code
    1. root@omv4:~# uname -a
    2. Linux omv4 4.14.0-0.bpo.2-amd64 #1 SMP Debian 4.14.7-1~bpo9+1 (2017-12-22) x86_64 GNU/Linux


    b. Welcher Treiber wurde geladen?

    Code
    1. root@omv4:~# modinfo ddbridge
    2. filename: /lib/modules/4.14.0-0.bpo.2-amd64/updates/dkms/ddbridge.ko
    3. version: 0.9.28
    4. license: GPL
    5. author: Ralph and Marcus Metzler, Metzler Brothers Systementwicklung GbR
    6. description: Digital Devices PCIe Bridge
    7. srcversion: B7D0071B39C2757EF6A1654
    8. alias: ...
    9. ...
    10. ...


    c. Was verrät uns dmesg?

    Code
    1. root@omv4:~# dmesg | grep ddbridge
    2. root@omv4:~# dmesg | grep "Digital Devices"
    3. root@omv4:~# dmesg | grep DVB
    4. root@omv4:~# dmesg | grep -i dvb
    5. [ 11.257256] dvb_core: disagrees about version of symbol module_layout
    6. [ 11.257368] dvb_core: disagrees about version of symbol module_layout


    Erkenntnis: Der von mir manuell unter Kernel 4.9 installierte Treiber wurde geladen, funktioniert aber nicht mehr.


    4. Deinstallation des alten Treibers:


    5. Prüfen, ob nun der Kerneltreiber bekannt ist:


    6. Sicherheitshalber nochmal prüfen, ob der neue Treiber sauber geladen wird:

    Code
    1. root@omv4:~# modprobe ddbridge

    Ok, das sieht gut aus!


    7. Prüfen, ob mit dem neuen Kernel-Treiber alles sauber erkannt wird:


    Nun noch kurz den VDR starten... Tada, läuft! :wow Während ich mein Handeln hier gerade dokumentiere, schaue ich parallel TV und zappe dabei ein Bisschen hin und her.


    Ich halte euch auf dem Laufenden, ob alles läuft oder ob es irgendwo noch Probleme gibt.


    Vielen Dank für die ganze Arbeit die Ihr da investiert habt, inbesondere nst .


    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

  • Code
    1. root@omv4:~# modinfo ddbridge
    2. filename: /lib/modules/4.14.0-0.bpo.2-amd64/kernel/drivers/media/pci/ddbridge/ddbridge.ko
    3. version: 0.9.31intermediate-integrated
    4. [....]
    5. depends: dvb-core

    :/ ... Das sieht so aus, als würde Debian bzw. die Backports-Herrschaften auch nichts von staging-Modulen halten - die CXD2099-basierten Single-Flex Addons werden damit genausowenig laufen wie mit Fedora...

    Server: Gigabyte P35-DS4, Intel Core2Duo E6850, 4GB DDR2-RAM (Headless), Gentoo Linux x86_64 / Kernel 4.13.9 / DD CineCTv6+DuoFlex C/T/T2+DuoFlex C/C2/T/T2 w/Kernel Stock Drivers / TVHeadend-GIT-3356759d8

    HTPC: Gigabyte GA-EG41MF-US2H, Intel Core2Duo E7500, 2GB DDR2-RAM, NVIDIA GT610/1GB PCIe in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 )
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VDPAU+HD-Audio+LCDproc addon / Ubuntu Trusty 14.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

  • Hm..., ok, das ist ja bescheiden. Da ich ausschließlich freie Sender mit meiner Max S8 schaue, betrifft mich das nicht.


    Danke für die Info, das ist ja sicherlich auch für andere Debian Jessie User interessant.


    Bisher läuft alles einwandfrei. :)


    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

  • Hallo zusammen,


    was ist eigentlich aus dem Thema mit

    Code
    1. lnbh25_set_voltage(): I2C transfer error (-5)
    2. lnbh25_attach(): no LNBH25 found at I2C addr 0x0c

    geworden?


    Habe von einer Cine S2 v5.5 (mit DuoFlex) wegen permanenten Bildfehlern auf eine v7A (mit der alten DuoFlex) gewechselt. Jetzt habe ich genau die gleichen "Fehler" im Log:



    Habe die Karte sowohl in meinem Server (Supermicro Board, ESXi 6.5, Ubuntu 16.04 VM) als auch im HTPC (MSI Board, Ubuntu 17.10) und aktuellstem stable Kernel

    Code
    1. uname -a
    2. Linux vdr-wz 4.14.13-041413-generic #201801101001 SMP Wed Jan 10 10:02:53 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

    getestet und in beiden Systemen oben genannten "Fehler" erhalten.


    Die DVB Devices werden zwar angelegt

    Code
    1. /dev/dvb# ls -al
    2. insgesamt 0
    3. drwxr-xr-x 6 root root 120 Jan 13 19:48 .
    4. drwxr-xr-x 20 root root 3920 Jan 13 19:48 ..
    5. drwxr-xr-x 2 root root 120 Jan 13 19:48 adapter0
    6. drwxr-xr-x 2 root root 120 Jan 13 19:48 adapter1
    7. drwxr-xr-x 2 root root 120 Jan 13 19:48 adapter2
    8. drwxr-xr-x 2 root root 120 Jan 13 19:48 adapter3

    Aber Adapter0 bekommt garkeine Sender rein, Adapter 1 scheint zu funktionieren.


    Eine ddbridge.conf mit msi=0 oder msi=1 habe ich sowohl auf dem Server als auch im HTPC versucht, brachte aber leider keine Verbesserung.


    PCIe Steckplätze habe ich auch schon getauscht, leider ebenfalls ohne Erfolg. Stromkabel ist lediglich an der Duoflex angeschlossen, da ich einen Multiswitch habe.


    Hat jemand eine Idee was ich hier machen kann bevor ich mich an den Digital Devices Support wende?


    Danke,

    Alex

    Server: Supermicro X9SAE, Intel Xeon E3-1245v2, ESXi 6.5

    VDR VM: Ubuntu 16.04 LTS, 2x DD Cine S2, VDR 2.3.8

  • was ist eigentlich aus dem Thema mit

    Code
    1. lnbh25_set_voltage(): I2C transfer error (-5)
    2. lnbh25_attach(): no LNBH25 found at I2C addr 0x0c

    geworden?

    Das ist KEIN(!) Fehler bzw. in irgendeiner Form ein Problem, solange darauf

    Code
    1. [ 11.624073] i2c i2c-0: lnbh25_attach(): attached at I2C addr 0x08

    kommt. Das ist Teil des Probings des LNB Controllers auf zwei I2C Adressen. Wenn auf der ersten getesteten kein LNBH25 zu finden ist, poppt eben der I2C transfer error im Kernel Log auf. Ähnliches passiert übrigens auch beim STV0910 Demodulator - der kann je nach Hardware auf zwei unterschiedlichen Adressen zu finden sein. Wenn bei entsprechender Hardware auf der ersten nichts zu finden ist, gibts ein STV0910 I2C Error im Kernel Log.


    Solange am Ende der Initialisierung steht, dass die Frontends (ST STV0910) registriert wurden, ist alles in Ordnung. Im Umkehrschluss bedeutet das aber auch, dass speziell Dein Problem mit dem ersten Tuner woanders zu suchen ist (und ich wüsste offen gesagt nicht wo; der gesamte Treiberstack ist bei sehr vielen Leuten fehlerfrei und im Dualtuner-Betrieb im Einsatz - evtl. Hardwareproblem?).

    Server: Gigabyte P35-DS4, Intel Core2Duo E6850, 4GB DDR2-RAM (Headless), Gentoo Linux x86_64 / Kernel 4.13.9 / DD CineCTv6+DuoFlex C/T/T2+DuoFlex C/C2/T/T2 w/Kernel Stock Drivers / TVHeadend-GIT-3356759d8

    HTPC: Gigabyte GA-EG41MF-US2H, Intel Core2Duo E7500, 2GB DDR2-RAM, NVIDIA GT610/1GB PCIe in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 )
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VDPAU+HD-Audio+LCDproc addon / Ubuntu Trusty 14.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

  • Das ist KEIN(!) Fehler bzw. in irgendeiner Form ein Problem,....

    Alles klar, danke für die Info. Hatte schon rumgesucht, aber noch nirgends eine definitive Aussage dazu gefunden.


    Habe die TV Karte jetzt mal wieder in der Server eingebaut. Jetzt macht Adapter 1 die selben Probleme wie zuvor Adapter 0.


    Ist schon irgendwie merkwürdig. Die v5.5 konnte wenigstens auf alles Tunern einen "Lock" bekommen.


    Irgendjemand eine Idee was das sein könnte?


    Und im Syslog dann

    Code
    1. Jan 14 13:42:42 vdr vdr: [1237] frontend 1/0 timed out while tuning to channel 2 (ZDF HD), tp 111361

    Grüße,

    Alex


    Edit: Wenn ich die Duoflex Karte abklemme, dann gehen beide Adapter...

    Code
    1. dvb-fe-tool --femon -a0 -f0
    2. Lock (0x1f) Signal= -33,74dBm C/N= 18,30dB preBER= 0
    3. Lock (0x1f) Signal= -33,75dBm C/N= 18,30dB preBER= 0
    4. Lock (0x1f) Signal= -33,75dBm C/N= 18,40dB preBER= 0
    5. dvb-fe-tool --femon -a1 -f0
    6. Lock (0x1f) Signal= -33,01dBm C/N= 16,60dB preBER= 0
    7. Lock (0x1f) Signal= -32,99dBm C/N= 16,60dB preBER= 0
    8. Lock (0x1f) Signal= -32,98dBm C/N= 16,70dB preBER= 0

    Edit 2: Nachdem ich ein

    Code
    1. pciPassthru0.msiEnabled = "FALSE"

    in der VM wieder hinzugefügt habe, scheinen alle 4 Adapter zu funktionieren.


    Komischerweise wurde anders als bei der v5.5 die v7 aber auch ohne diese Einstellungen erkannt, weshalb ich diese jetzt beim Einbau der v7 weggelassen habe.


    Edit 3: Ich muss das korrigieren. Nach kurzer Zeit sind beide neuen Adapter (v7) nicht mehr ansprechbar und im Log finde ich dann

    Code
    1. Jan 14 19:36:55 vdr vdr: [6686] frontend 0/0 timed out while tuning to channel 1 (Das Erste HD), tp 111493

    Erst nach einem reboot der VM geht Adapter0 dann wieder, Adapter 1 weiterhin nicht. Irgendwer eine Idee was das sein kann?


    Edit4: Habe nach einem Reboot der VM eine Aufnahme auf Adapter 0 gestartet, die auch durchlief und laut vdr-checkts auch keine Fehler hatte. Nachdem die Aufnahme fertig war, scheint der VDR jetzt keinen Zugriff mehr auf Adapter 0 zu bekommen. Im Log finde ich jetzt lauter

    Code
    1. an 14 21:52:55 vdr vdr: [1365] frontend 0/0 timed out while tuning to channel 185 (Aristo.TV), tp 111273
    2. Jan 14 21:53:16 vdr vdr: [1365] frontend 0/0 timed out while tuning to channel 2 (ZDF HD), tp 111361
    3. Jan 14 21:53:37 vdr vdr: [1365] frontend 0/0 timed out while tuning to channel 1 (Das Erste HD), tp 111493
    4. Jan 14 21:53:58 vdr vdr: [1365] frontend 0/0 timed out while tuning to channel 9 (PHOENIX HD), tp 111582
    5. Jan 14 21:54:40 vdr vdr: [1365] frontend 0/0 timed out while tuning to channel 229 (Dlf Kultur), tp 111953
    6. Jan 14 21:56:04 vdr vdr: [1365] frontend 0/0 timed out while tuning to channel 290 (Radio Freundes-Dienst), tp 112515
    7. Jan 14 21:56:25 vdr vdr: [1365] frontend 0/0 timed out while tuning to channel 55 (WDR HD Aachen), tp 112604
    8. Jan 14 21:57:07 vdr vdr: [1365] frontend 0/0 timed out while tuning to channel 87 (CNBC Europe), tp 211597

    Wie hier schon jemand schrieb, hilft es dann den Treiber zu entladen und neu zu laden. Der VDR hat dann wieder Zugriff auf die Adapter. Habe bis auf das live Plugin keine weiteren Plugins während der Tests geladen.


    Edit 5: Habe nochmal die VM neu gestartet und dann mit dvb-fe-tool auf den Adapter geschaut was passiert. Nach ziemlich genau 20 Minuten verliert der VDR den Lock auf den Adapter:

    Code
    1. Jan 14 22:28:31 vdr vdr: [1309] frontend 0/0 timed out while tuning to channel 38 (Franken Fernsehen HD), tp 110714
    2. uptime
    3. 22:29:59 up 22 min, 2 users, load average: 0,15, 0,24, 0,19

    Due DuoFlex geht zu dem Zeitpunk aber weiterhin:

    Code
    1. root@vdr:/# dvb-fe-tool --femon -a2 -f0
    2. Lock (0x1f) Signal= 75,00% C/N= 36,00% postBER= 1
    3. Lock (0x1f) Signal= 76,00% C/N= 36,00% postBER= 1
    4. ^CLock (0x1f) Signal= 76,00% C/N= 36,00% postBER= 1
    5. ERROR FE_SET_VOLTAGE: Vorgang nicht zulässig
    6. root@vdr:/# dvb-fe-tool --femon -a3 -f0
    7. Lock (0x1f) Signal= 76,00% C/N= 33,60% postBER= 0
    8. Lock (0x1f) Signal= 76,00% C/N= 33,80% postBER= 0
    9. ^CERROR FE_SET_VOLTAGE: Vorgang nicht zulässig

    Server: Supermicro X9SAE, Intel Xeon E3-1245v2, ESXi 6.5

    VDR VM: Ubuntu 16.04 LTS, 2x DD Cine S2, VDR 2.3.8

    Dieser Beitrag wurde bereits 8 Mal editiert, zuletzt von Honker ()

  • Habe sicherheitshalber den VDR nochmal neu gebaut, um auch hier Probleme auszuschließen. Brachte jedoch auch keinen Erfolg. Diesmal war nach einem Reboot Adapter 0 nahezu (unter 5 Minute) für den VDR weg. Adapter 1 habe ich zur zeit per udev Regel deaktiviert.


    Werde heute Abend mal ohne angesteckte DuoFlex testen, ob der VDR dann ebenfalls den Zugriff auf den/die Adapter von der v7 verliert.

    Server: Supermicro X9SAE, Intel Xeon E3-1245v2, ESXi 6.5

    VDR VM: Ubuntu 16.04 LTS, 2x DD Cine S2, VDR 2.3.8

  • Habe mit der abgeklemmten DuoFlex das selbe Problem.


    Habe eine Aufnahme programmiert und wenn der VDR dann versucht auf die Karte zuzugreifen, bekommt er ein timeout:


    Wenn ich dann den VDR stoppe, ddbridge entlade, neu lade und den VDR wieder starte, hat der VDR wieder Zugriff auf den Adapter.


    Habe schon SAT Kabel zwischen den Adaptern getauscht, hat aber auch keine Verbesserung gebracht...

    Server: Supermicro X9SAE, Intel Xeon E3-1245v2, ESXi 6.5

    VDR VM: Ubuntu 16.04 LTS, 2x DD Cine S2, VDR 2.3.8