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

  • Bei mir hier genau das Selbe: :(


    Evtl. kann Tinitus dazu genauere Auskunft geben, bei ihm hats ja letztendlich geklappt. Hinweise übernehm' ich gerne in den HowTo-Wiki-Artikel.

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

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 ), Kodi v18 Leia
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

  • Habe den Fehler gefunden, nun geht's. :]


    Code
    1. server02 media_build # modprobe -v ddbridge
    2. insmod /lib/modules/4.4.5-gentoo/kernel/drivers/media/media.ko
    3. insmod /lib/modules/4.4.5-gentoo/kernel/drivers/media/dvb-core/dvb-core.ko
    4. insmod /lib/modules/4.4.5-gentoo/kernel/drivers/staging/media/cxd2099/cxd2099.ko
    5. insmod /lib/modules/4.4.5-gentoo/kernel/drivers/media/pci/ddbridge/ddbridge.ko
    6. server02 media_build #
  • Habe den Fehler gefunden, nun geht's. :]



    Kannst Du die Ausgabe von lsmod (komplett) und dmesg (komplett) mal pastebin'en und Deine genauen Kartentypen (Bridge-Karte, DuoFlex-Module usw.) durchgeben? Funktioniert mit der Konstellation alles?


    ^ ^ Danke!

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

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 ), Kodi v18 Leia
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

  • Leider funktionieren damit meine Realtek RTL2832U Sticks nicht. :(


    Code
    1. [Sa Mär 12 21:11:41 2016] usb 1-1.3.4: New USB device found, idVendor=0bda, idProduct=2838
    2. [Sa Mär 12 21:11:41 2016] usb 1-1.3.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    3. [Sa Mär 12 21:11:41 2016] usb 1-1.3.4: Product: RTL2838UHIDIR
    4. [Sa Mär 12 21:11:41 2016] usb 1-1.3.4: Manufacturer: Realtek
    5. [Sa Mär 12 21:11:41 2016] usb 1-1.3.4: SerialNumber: 00000001
    6. [Sa Mär 12 21:11:41 2016] usb 1-1.3.4: dvb_usb_v2: found a 'Realtek RTL2832U reference design' in warm state
    7. [Sa Mär 12 21:11:41 2016] usb 1-1.3.4: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer
    8. [Sa Mär 12 21:11:41 2016] dvb_usb_rtl28xxu: probe of 1-1.3.4:1.0 failed with error -23
  • Leider funktionieren damit meine Realtek RTL2832U Sticks nicht. :(

    Code
    1. [Sa Mär 12 21:11:41 2016] dvb_usb_rtl28xxu: probe of 1-1.3.4:1.0 failed with error -23


    Die Sticks kenn' ich nicht und der Code wird im ddbridge-Repo auch nicht angefasst. -23 (ENFILE) liest sich aber nach "Kann kein Device Node erzeugen".

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

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 ), Kodi v18 Leia
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)


  • Yep, das klappt so (mein Server läuft ebenfalls auf Gentoo+gentoo-sources-4.4.x, mit Modulen erzeugt durch media_build) - der Branch ist richtig ;-)


    So, bin nun zum Testen gekommen. Statt "make stagingconfig" habe ich "make menuconfig" benutzt und wie bei media_build_experimental nur die Treiber ausgewählt, die benötigt werden. Leider schlägt das Laden des tda18212-Treibers fehl:


    Kernel ist 4.4.5.

  • Code
    1. [ 1406.490912] tda18212: Unknown symbol __devm_regmap_init_i2c (err 0)


    Du brauchst CONFIG_REGMAP_I2C aus Deinem "regulären" Kernel (lt. Kconfig unter "Device Drivers => Generic Driver Options", da find ich die Option aber grad' nicht...). Den Hinweis pack' ich direkt mal ins Howto. EDIT: Done.


    Nebenbei, lassen sich die Module in dem Zustand alle (inkl. ddbridge) sauber entladen? Das war eine der Baustellen, die sich beim Experimentieren aufgetan haben...

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

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 ), Kodi v18 Leia
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)


  • Du brauchst CONFIG_REGMAP_I2C aus Deinem "regulären" Kernel (lt. Kconfig unter "Device Drivers => Generic Driver Options", da find ich die Option aber grad' nicht...). Den Hinweis pack' ich direkt mal ins Howto. EDIT: Done.


    Ich finde die Option auch nicht. CONFIG_REGMAP_I2C steht bei mir auch in keiner alten Kernelconfig, mit der die Karte bisher immer lief.



    Du mußt die Kernelsourcen zu 4.4 installieren....


    sys-kernel/linux-headers
    Available versions: *2.4.33.3^bs ~*2.4.36^bs 3.18^bs ~3.19^bs ~4.0^bs ~4.1^bs ~4.2^bs 4.3^bs (~)4.4^bs
    Installed versions: 4.4^bs(11:45:00 12.03.2016)
    Homepage: https://www.kernel.org/ https://www.gentoo.org/
    Description: Linux system headers


    Danke, ich hatte noch Version 4.3 installiert. Hat aber leider auch nichts genützt. Beim Kompilieren der Treiber erscheint immer noch

    Code
    1. WARNING: "__regmap_init_i2c" [/usr/src/dvbdev/media_build/v4l/ts2020.ko] undefined!
    2. WARNING: "__devm_regmap_init_i2c" [/usr/src/dvbdev/media_build/v4l/tda18212.ko] undefined!
    3. WARNING: "__devm_regmap_init_i2c" [/usr/src/dvbdev/media_build/v4l/tda10071.ko] undefined!
    4. WARNING: "__devm_regmap_init_i2c" [/usr/src/dvbdev/media_build/v4l/m88ds3103.ko] undefined!

    , obwohl ich auch schon den Kernel neu gebaut und bei media_build ein "make distclean" gemacht habe.



    Nebenbei, lassen sich die Module in dem Zustand alle (inkl. ddbridge) sauber entladen? Das war eine der Baustellen, die sich beim Experimentieren aufgetan haben...


    Sieht so aus. Es erscheint zwei Mal "release" im Log und danach lässt sich der Treiber erneut laden.


    Edit: Ohne den tda18212-Treiber gibt es eine Null-Pointer Dereferenz, wenn der VDR startet:

  • Ich finde die Option auch nicht. CONFIG_REGMAP_I2C steht bei mir auch in keiner alten Kernelconfig, mit der die Karte bisher immer lief.


    Dann probier' mal: /usr/src/linux/.config im Texteditor öffnen, nach CONFIG_REGMAP suchen und dann von Hand CONFIG_REGMAP=y, CONFIG_REGMAP_I2C=m und CONFIG_REGMAP_MMIO=y setzen (so sieht das in meiner .config aus). Dann make / make modules_install / depmod -a. Dann nochmal ddbridge laden.


    Die Karte lief vorher ohne die Option, da das tda18212dd-Modul nicht davon abhängt, der Testing-Branch enthält aber eine Änderung, die das zusätzliche Modul überflüssig macht und stattdessen das vom Kernel "mitgelieferte" tda18212-Tunerfrontend verwendet, und das wird über die Regmap-API adressiert.



    Sieht so aus. Es erscheint zwei Mal "release" im Log und danach lässt sich der Treiber erneut laden.


    Edit: Ohne den tda18212-Treiber gibt es eine Null-Pointer Dereferenz, wenn der VDR startet:


    EDIT: :( .. doch noch nicht gefixt.

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

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 ), Kodi v18 Leia
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)


  • EDIT: :( .. doch noch nicht gefixt.


    Diese Änderung sollte das jetzt wirklich fixen, am besten 1x den Kerneltree+Branch vom GIT neu holen, media_build ackern lassen, und dann "make install" :-)

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

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 ), Kodi v18 Leia
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)


  • Dann probier' mal: /usr/src/linux/.config im Texteditor öffnen, nach CONFIG_REGMAP suchen und dann von Hand CONFIG_REGMAP=y, CONFIG_REGMAP_I2C=m und CONFIG_REGMAP_MMIO=y setzen (so sieht das in meiner .config aus). Dann make / make modules_install / depmod -a. Dann nochmal ddbridge laden.


    Hat leider auch nicht funktioniert. Sobald ich make eingebe, schreibt er die .config neu und schmeißt die Änderungen wieder raus. Ich habe jetzt einfach andere Optionen bzw. Treiber gesucht, die CONFIG_REGMAP_I2C und CONFIG_REGMAP_MMIO als Abhängigkeit haben. Das sind z.B. Device Drivers/Character Devices/Serial drivers/SC16IS7xx serial support (dort den Unterpunkt I2C aktivieren) und Device Drivers/Multifunction device drivers/System Controller Register R/W Based on Regmap. Jetzt lädt der Treiber:



    VDR läuft auch, super!


    Die Karte lief vorher ohne die Option, da das tda18212dd-Modul nicht davon abhängt, der Testing-Branch enthält aber eine Änderung, die das zusätzliche Modul überflüssig macht und stattdessen das vom Kernel "mitgelieferte" tda18212-Tunerfrontend verwendet, und das wird über die Regmap-API adressiert.


    Ah, OK.



    EDIT: :( .. doch noch nicht gefixt.


    Zur Klarstellung: Der Fehler kam schon direkt nach dem Booten beim VDR-Start. Beim reinen Entladen und erneuten Laden des Treibers kommt kein Fehler.

  • Ich habe jetzt einfach andere Optionen bzw. Treiber gesucht, die CONFIG_REGMAP_I2C und CONFIG_REGMAP_MMIO als Abhängigkeit haben. Das sind z.B. Device Drivers/Character Devices/Serial drivers/SC16IS7xx serial support (dort den Unterpunkt I2C aktivieren) und Device Drivers/Multifunction device drivers/System Controller Register R/W Based on Regmap.


    Alternativ einfach den TDA18212 Tuner aus "Device Drivers / Multimedia support / Customize TV tuners" aktivieren (nur sichtbar, wenn "Autoselect ancillary drivers" deaktiviert ist) :-) Das Modul wird dann durch media_build ersetzt.


    Jetzt lädt der Treiber:

    Code
    1. [ 3525.184272] stv0367 found
    2. [ 3525.450983] tda18212 7-0060: NXP TDA18212HN/M successfully identified
    3. [ 3525.451006] ddbridge 0000:05:00.0: DVB: registering adapter 0 frontend 0 (STV0367 DVB-C DVB-T)...
    4. [ 3525.452461] stv0367 found
    5. [ 3525.718215] tda18212 7-0063: NXP TDA18212HN/S successfully identified
    6. [ 3525.718240] ddbridge 0000:05:00.0: DVB: registering adapter 1 frontend 0 (STV0367 DVB-C DVB-T)...


    Super, sehr schöne Sache!


    VDR läuft auch, super!


    :tup


    Zur Klarstellung: Der Fehler kam schon direkt nach dem Booten beim VDR-Start. Beim reinen Entladen und erneuten Laden des Treibers kommt kein Fehler.


    Ja, sobald irgendwas versucht hat, das DVB Frontend wirklich zu benutzen, hats geknallt - das Demod Frontend war da, aber kein Tuner, und der Fehlerfall (tda18212_attach failed) wurde nicht nach unten durchgereicht und einfach mit DVB-Frontend Registierung fortgefahren. Beim Zugriff fehlte dann der Tuner und wurde mit NULL referenziert -> Bumm (vgl. #251). In einer früheren Code-Revision sind dann die Referenzen bzgl. Modulverwendungen im Kernel Amok gelaufen und rmmod ist einfach eingefroren und konnte nicht mal mit kill -TERM entfernt werden...


    Vielen Dank für Tests und Feedback!

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

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 ), Kodi v18 Leia
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

  • Diese Änderung sollte das jetzt wirklich fixen, am besten 1x den Kerneltree+Branch vom GIT neu holen, media_build ackern lassen, und dann "make install" :-)


    Mit der Änderung sieht es jetzt so aus, wenn z.B. regmap-i2c fehlt und der Tunertreiber nicht lädt:


    Beim VDR-Start kommt keine Fehlermeldung mehr.



    Vielen Dank für Tests und Feedback!


    Gern geschehen. In erster Linie muß ich Dir aber dafür danken, daß Du Dich der Sache angenommen hast! Wenn das dazu führt, daß er Treiber irgendwann im Kernel landet, wäre das echt spitze.

  • Hallo zusammen,


    ein bisschen was Gutes, aber auch was ziemlich Schlechtes neues:

    • Gut: Die Verwendung vom In-Tree TDA18212-Tuner als I2C-Client funktioniert mit den kleinen Ergänzungen im GIT jetzt allem Anschein nach richtig ordentlich und stabil - Nach mehrmaligem Ent- und Neuladen von ddbridge und zugehörigen Modulen sowie Poweroff-Neustarts des Servers gibt es keinerlei Probleme mehr, das Tuner-Frontend sowohl an den STV0367-Demod als auch den CXD2837-Demod anzuhängen. @gentoo-vdr: Kannst Du das bestätigen?
    • Gut, aber am Ende dann doch schlecht: Das Refcount-Problem von ddbridge ("rmmod ddbridge - Use count -1") beim Testen mit dem In-Tree STV0367-Demod-Modul scheint behoben. Offenbar hat hier der Locking-Mechanismus in ddbridge (der für alle C/T Frontends verwendet wird) für erhebliche Probleme gesorgt (deadlock). stv0367(non-dd) darf jetzt fehlschlagen, falsch initialisieren (dann funktioniert auch der Tuner nicht) und/oder mit i2c-Fehlern um sich schmeissen, das ddbridge-Modul ist ohne Probleme zu entladen.
    • Gut: Das In-Tree STV0367-Modul schafft es anscheinend, dem Demod Dinge wie Signalstärke zu entlocken. Während mit den DD-Varianten im TVHeadend nur "SNR 1, Strength 0" gezeigt werden, tauchen mit dem In-Kernel-Treiber tatsächlich nach Tuning nutzbare Informationen auf ;-)
    • Schlecht: STV0367+TDA18212 initialisieren nur dann vollständig, wenn zuvor mit STV0367DD initialisiert wurde. Ansonsten lässt sich der Tuner nicht anhängen.
    • Sehr schlecht: Der Versuch, beide DVB-Varianten (C+T) gleichzeitig zu attachen, führt zu I2C-Fehlerspam im Kernellog, sobald die DVB Adapter verwendet werden (egal, ob im C- oder T-Modus). Es scheint also nur eins von beiden zu funktionieren. Nebeneffekt: Nach diesem Zustand meldet die Bridge, dass an Port 0 angeblich nichts mehr angeschlossen ist - Poweroff-Reboot erforderlich.
    • Ebenfalls sehr schlecht: Nur eine der Varianten anhängen funktioniert zwar inkl. Tunen, aber es werden keinerlei Daten (Transportstream) geliefert. Ausserdem bleibt das genannte Init-Problem.


    Mit anderen Worten: Der Kram initialisiert und registriert sich wenn man vorarbeitet, ist aber im Endeffekt nicht nutzbar.


    Da sich stv0367 und stv0367dd strukturell ziemlich heftig unterscheiden (stv0367dd stellt ein einzelnes Frontend für C+T zur Verfügung, vs. zwei Schnittstellen in stv0367), in beiden Modulen jede Menge Register-Poking stattfindet und ausserdem anscheinend noch Dinge wie richtige Taktfrequenzen und Takt auf steigender/fallender Flanke usw. zum Tragen kommen, muss ich an der Baustelle erstmal aufgeben.


    Falls wer jemanden kennt, der bereit ist, bei der Baustelle zu helfen... ?(


    Alle anderen Baustellen sollten - der Historie der Media-Mailinglist nach zu urteilen - mit 'nem bisschen weiteren Code-Anhübschen IMHO bereit für einen ersten Mailinglist-Anlauf sein (drxk/stv0910/stv6111/lnbh25-Feedback noch ausstehend). STV0367DD wird es aber tendenziell nicht in Mainline schaffen (O-Ton: "We already have a driver" - Reply auf Maik Broemme's Patch), und ohne siehts für CineCTv6-User (und ggf. DuoFlex C/T ohne T2) schlecht aus.


    Den aktuellen Experimental-Kram gibts im mediatree/master-ddbridge-testing-stv Branch zu sehen.


    Grüße,
    Daniel

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

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 ), Kodi v18 Leia
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

  • Du könntest vielleicht mal bei Antti Palosaari nachfragen. Mit ihm hatte ich schon Kontakt wegen den dddvb Treibern.
    Er hat da schon beachtliches Wissen in der Richtung und könnte da sicherlich behilflich sein.


    Er wollte den Treiber sogar schonmal sauber in den Kernel integrieren. Gescheitert ist das soweit ich mich erinnere, dass er gerne Hardware von Digital Devices gestellt bekommen wollte.
    Ob überhaupt Kommunikation zwischen DD und Antti stattgefunden hat, kann ich nicht sagen. Ich habe mal eine Zeit lang zwischen beiden vermittelt und hatte dann direkten Kontakt vorgeschlagen.

  • Gut: Die Verwendung vom In-Tree TDA18212-Tuner als I2C-Client funktioniert mit den kleinen Ergänzungen im GIT jetzt allem Anschein nach richtig ordentlich und stabil - Nach mehrmaligem Ent- und Neuladen von ddbridge und zugehörigen Modulen sowie Poweroff-Neustarts des Servers gibt es keinerlei Probleme mehr, das Tuner-Frontend sowohl an den STV0367-Demod als auch den CXD2837-Demod anzuhängen. @gentoo-vdr: Kannst Du das bestätigen?


    Kann ich bestätigen. Bisher sind mir keine Probleme aufgefallen und alles läuft stabil. Entladen des Treibers verwende ich nicht bei meinem VDR, ich habe es aber ein paar Mal getestet und keine Probleme feststellen können. Den CXD2837-Demod habe ich bei mir nicht, nur stv0367dd.


    Der Rest von dem Du schreibst, ist leider nicht so erfreulich. Hast Du schon jemanden gefunden, der Dir bei der Baustelle weiterhelfen kann? Falls nicht, könntest Du vielleicht mal vorsichtig bei UFO anfragen. Wenn Deine Anstrenungen dazu führen, daß der DD-Treiber im Kernel landet und er keine Supportanfragen zu media_build_experimental mehr beantworten muss, ist das glaube ich auch in seinem Interesse. Alternativ fällt mir rjkm ein. Ist er nicht der Autor des DD-Treibers? Ansonsten scheint sich jasminj auch gut auszukennen, nachdem was ich hier so im Forum gelesen habe.


  • Kann ich bestätigen. Bisher sind mir keine Probleme aufgefallen und alles läuft stabil. Entladen des Treibers verwende ich nicht bei meinem VDR, ich habe es aber ein paar Mal getestet und keine Probleme feststellen können. Den CXD2837-Demod habe ich bei mir nicht, nur stv0367dd.


    Das einzige Problem, was mir jetzt noch aufgefallen ist: Nach mehrmaligem ent-/neuladen des ddbridge-Moduls scheinen dem Kernel irgendwie die Resourcen auszugehen (Memleak in ddbridge irgendwo?) und das System muss gebootet werden. Dabei hat sich dann - vor wenigen Minuten - das stv0367dd-Modul mit i2c_write-Fehlern ins Kernel-Log erbrochen, dadurch hat dann das Tuner-Attachen nicht geklappt. War soweit kein Problem, aber nach rmmod/modprobe ddbridge war dann angeblich am Port wieder mal nichts angeschlossen. Nach Powercycle und somit Cold-Boot war dann alles gut, und der Tuner konnte auch (nach dem Coldboot) gestartet werden. Bisschen seltsam alles, aber nuja...


    Der Rest von dem Du schreibst, ist leider nicht so erfreulich. Hast Du schon jemanden gefunden, der Dir bei der Baustelle weiterhelfen kann? Falls nicht, könntest Du vielleicht mal vorsichtig bei UFO anfragen. Wenn Deine Anstrenungen dazu führen, daß der DD-Treiber im Kernel landet und er keine Supportanfragen zu media_build_experimental mehr beantworten muss, ist das glaube ich auch in seinem Interesse. Alternativ fällt mir rjkm ein. Ist er nicht der Autor des DD-Treibers? Ansonsten scheint sich jasminj auch gut auszukennen, nachdem was ich hier so im Forum gelesen habe.


    Ehrlich gesagt hab' ich mich bislang nicht weiter um diese Baustelle bemüht (ich hübsch' grad' das CXD2843-Demod-Modul an - und nebenbei ist die Ausgabe bzw. Anzeige von Signal-Stärke/Signalqualität für DVB-T/T2/C dazugekommen ;-) ).


    Was die beiden STV0367-Implementierungen angeht: Es gibt unheimlich viele Ähnlichkeiten (auch wie der Demod vom Modul aus programmiert wird), aber an einigen anscheinend entscheidenden Stellen sind eben doch Unterschiede (Im in-tree-Modul wird z.B. komplett auf Programmierung der Tuneransteuerung verzichtet). Nach aktuellem Stand ergeben sich zwei Optionen: Entweder 1-2 zusätzliche Config-Optionen in struct stv0367_config und einem relativ ausgeprägtem Rattenschwanz an if/else, oder (ebenfalls per Option) den DD-Code als zusätzliche Variante einpflegen (viel duplizierter Code). Oder aber Option 3: Die DD-Variante as-is an die Liste schicken (Coding Style ist bereits angepasst/gefixt).


    Ich werd' dazu auch noch versuchen, Antti Palosaari anzutriggern, aber eins nach dem anderen. Bzgl. media_build_experimental - im HG-Repository hat sich auch schon länger nichts mehr getan, ist UFO noch aktiv?

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

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 ), Kodi v18 Leia
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

  • Das einzige Problem, was mir jetzt noch aufgefallen ist: Nach mehrmaligem ent-/neuladen des ddbridge-Moduls scheinen dem Kernel irgendwie die Resourcen auszugehen (Memleak in ddbridge irgendwo?) und das System muss gebootet werden. Dabei hat sich dann - vor wenigen Minuten - das stv0367dd-Modul mit i2c_write-Fehlern ins Kernel-Log erbrochen, dadurch hat dann das Tuner-Attachen nicht geklappt. War soweit kein Problem, aber nach rmmod/modprobe ddbridge war dann angeblich am Port wieder mal nichts angeschlossen.


    Tatsächlich, bei mir gab es jetzt auch einen Fehler beim 4. oder 5. Neuladen des Treibers:


    Ich muß dazu sagen, daß ich den Treiber sehr schnell hintereinander ent- und wieder neu geladen habe. Möglicherweise gibt es da einen Zusammenhang.


    Ehrlich gesagt hab' ich mich bislang nicht weiter um diese Baustelle bemüht (ich hübsch' grad' das CXD2843-Demod-Modul an - und nebenbei ist die Ausgabe bzw. Anzeige von Signal-Stärke/Signalqualität für DVB-T/T2/C dazugekommen ;-) ).


    Was die beiden STV0367-Implementierungen angeht: Es gibt unheimlich viele Ähnlichkeiten (auch wie der Demod vom Modul aus programmiert wird), aber an einigen anscheinend entscheidenden Stellen sind eben doch Unterschiede (Im in-tree-Modul wird z.B. komplett auf Programmierung der Tuneransteuerung verzichtet). Nach aktuellem Stand ergeben sich zwei Optionen: Entweder 1-2 zusätzliche Config-Optionen in struct stv0367_config und einem relativ ausgeprägtem Rattenschwanz an if/else, oder (ebenfalls per Option) den DD-Code als zusätzliche Variante einpflegen (viel duplizierter Code). Oder aber Option 3: Die DD-Variante as-is an die Liste schicken (Coding Style ist bereits angepasst/gefixt).


    Ich werd' dazu auch noch versuchen, Antti Palosaari anzutriggern, aber eins nach dem anderen. Bzgl. media_build_experimental - im HG-Repository hat sich auch schon länger nichts mehr getan, ist UFO noch aktiv?


    Alles klar, kein Stress :) Ob UFO noch aktiv ist, weiß ich nicht. Im Forum war er anscheinend schon länger nicht mehr unterwegs, vielleicht reagiert er aber auf eine PN, wenn Deine anderen Versuche im Sand verlaufen.

  • Zwischenstand (interessant für alle Tester):


    Ich habe heute alle Commits aus dem -testing Branch in die passenden Commits im "Basisbranch" (mediatree/master-ddbridge) eingefügt (squash), das zusätzliche Tuner-Module TDA18212DD ist jetzt verschwunden (Feedback und eigene Tests haben die Anpassung für stabil befunden). Ebenfalls sind die funktionalen Anhübschungen (und diverse kleinere Code-Refaktorierungen) vom CXD2843 jetzt drin. Abgesehen von CamelCase sollte der Treiber jetzt zumindest mal einen potentiellen Kandidaten für linux-media darstellen.


    Die darauf aufsetzenden Branches sind entsprechend rebased.



    Tatsächlich, bei mir gab es jetzt auch einen Fehler beim 4. oder 5. Neuladen des Treibers:

    Code
    1. [...]
    2. [Mo Mär 21 22:36:11 2016] stv0367: i2c_write error
    3. [Mo Mär 21 22:36:11 2016] tda18212: probe of 7-0063 failed with error -5
    4. [Mo Mär 21 22:36:11 2016] ddbridge 0000:05:00.0: TDA18212 tuner not found. Device is not fully operational.
    5. [Mo Mär 21 22:36:11 2016] release
    6. [Mo Mär 21 22:36:11 2016] port_attach on port 0 failed


    Ich muß dazu sagen, daß ich den Treiber sehr schnell hintereinander ent- und wieder neu geladen habe. Möglicherweise gibt es da einen Zusammenhang.


    War anschliessend auch der Port an der Karte angeblich nicht belegt?


    Die Problem(chen) scheinen irgendwie nicht wirklich reproduzierbar zu sein. Ich habe alleine heute bestimmt schon 3x die Kernelmodule zwecks Tests ent- und neu geladen, keine Probleme... Ich vermute, dass entweder der Demod in einem "komischen" Zustand ist, während er initialisiert wird (und sich im Anschluss einfach komplett aufhängt), oder der I2C Code in ddbridge die Ports etwas "kräftiger" resetten könnte. Beides sind aber Dinge, die sich gerne jemand anderes anschauen darf :D 8)


    EDIT: Commit-ID nach Rebase und Squash dreier Minor-Fixes in CXD2843.

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

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 ), Kodi v18 Leia
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

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