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

  • Nabend zusammen,


    da gerade der linux-media Pull Request für Kernel 4.16 gemerged wurde, einfach mal 'ne kurze Zusammenfassung, was mit 4.16 für DD-Kartenuser an Neuerungen kommt (4.15 hat nur kosmetische Code-Cleanups erhalten):


    • Noch mehr kosmetische Cleanups und Mini-Fixes in allen DD-relevanten Kernelmodulen (ddbridge, stv0910, stv6111, mxl5xx sowie cxd2099).
    • ddbridge Version 0.9.32 (auch wenn der Versionstag eins höher ist, gibts für Tuner- und CI-Karten User funktional nichts neues).
    • Die Fehlerbehandlung in ddbridge beim Demod/Tuner-Attach wurde ordentlich verbessert. Egal, zu welcher Zeit der Karten- bzw. Flexmodul-Init in Fehler läuft, hinterlässt ein Fehler jetzt keine Artefakte mehr im Kernel (memleaks, OOPSes usw.) oder geladene Module mit kaputtem Refcount, die sich nicht mehr entladen lassen.
    • Weiterhin werden "restliche" funktionierende Tunermodule jetzt in einen funktionsfähigen Zustand initialisiert und können verwendet werden. ddbridge meldet erst dann eine fehlgeschlagene Initialisierung an die Kernel-Subsysteme zurück, wenn wirklich gar nichts initialisiert werden konnte. Teilweise fehlgeschlagene Initialisierungen werden entsprechend als Warning im Kernel Log dokumentiert.
    • Im stv0910/stv6111 Demod/Tuner-Stack (CineS2 V7 und DuoFlex S2 V4) wurde ein potentielles Deadlocking-Problem gefixt, welches durch fehlgeschlagene I2C-Transfers während des Tuner-Zugriffs ausgelöst werden konnte.
    • Das DVB Subsystem kann jetzt mit DVB-S2(X) "Physical Layer Scrambling" umgehen. Der STV0910-Treiber hat diesbzgl. Unterstützung erhalten (der STV090x-Treiber - CineS2 V6.5 und ältere S2 Flex - hat diese von anderer Steller erhalten).

    Für 4.17 derzeit queued (hätte eigentlich auch in 4.16 landen sollen, wurde aus unerfindlichen Gründen aber nicht merged):

    • Mehr Support (enums/Konstanten) für DVB-S2X wie neue Modulationsverfahren (APSK32+) u.a.
    • Physical Layer Scrambling Support für den mxl5xx (MaxS8 4/8).
    • (noch nicht gepostet) Ein Fix für die MiniDiSEqC Burst Übertragung im stv0910.

    Viele Grüße,

    nst

    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)

  • Danke für die Info!

    -> Ich las I2C....

    Könnte das die I2C Timeout Problematik auf Asrock Boards fixen??

    [Cine S2 V6.5 + DuoFlex V4] zur Zeit wieder ngene basierte Cine S2 / Apollo-Lake Celeron (Asrock J3355M), ATRIC Einschalter, yaVDR0.61

  • Könnte das die I2C Timeout Problematik auf Asrock Boards fixen??

    Nein (das ist ein Problem zwischen Board und Karte bzw. dessen FPGA und nach aktuellem Kenntnisstand nicht per Treiberupdate fixbar), aber das System läuft nicht mehr in Gefahr, im Kernel zu deadlocken, wenn sich Karte und PCIe-Bus voneinander verabschieden.

    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)