Posts by nst

    Servus zusammen,


    habe ein Stück "alte" ngene-Hardware (L4M/DD Cine S2 V5.5) in die Finger bekommen und hab' mal den Treiber ein bisschen frisiert:


    • Es werden jetzt so ziemlich alle derzeit erhältlichen DuoFlex-Module erkannt und unterstützt (an den Expansion-Connector der v5.5 angeschlossen), inkl. aller DuoFlex CT2/C2T2/C2T2I und der DuoFlex S2 V4. Ausnahme: Die DuoFlex Twin-CI Adapter.
    • Der Treiber beschwert sich nicht mehr, wenn kein CI-Flex angeschlossen ist.
    • Der Treiber schreibt seinen Kram jetzt anständig mit PCI Port Angaben ins Kernel Log (dev_*() logging vs. printk())
    • Diverse Mini-Verbesserungen


    Sofern noch Leute mit derartiger Hardware unterwegs sind (cineS2v5.5, Mystique SaTiX S2, DD DuoFlex PCIe Bridge mit zwei Ports) - mir fallen hier mehr oder weniger spontan DaGo   Grillbert   Grumpy ein - wärs toll, wenn v.a. die erweiterte Hardware-Unterstützung mal getestet werden könnte. Speziell die Unterstützung für die S2 V4 wäre spannend (derzeit noch ungetestet), der Betrieb an den alten mini-Bridges am ersten Port wäre aber auch interessant. Die Changes möchte ich gerne in mainline unterbringen, sprich, auf linux-media posten.


    Branch: mediatree/master-ngene

    Commits: mediatree/master-ddb-cxd2099 -> mediatree/master-ngene

    Anleitung/Compile-Howto: Compile using media_build


    Bitte anstatt "mediatree/master-ddbridge" dann "mediatree/master-ngene" auschecken und damit dann media_build befüttern (prinzipiell dasselbe Vorgehen wie schon bei den ddbridge-Tests ;))


    EDIT: Ich habe noch einen use-after-free Kernel-OOPS gefixt (verursacht durch das Cleanup des TDA18212 Tuner I2C Clients), der beim Entladen der Module aufgetreten ist, wenn ein CXD2099 am Expansion Port angeklemmt ist.


    Viele Grüße,

    nst

    Nachtrag (Cc/Ping kls dazu):


    Wenig überraschend funktionierts mit dem NULL Packet PID Filter Patch in mtd.c (kein Pixelbrei, kein Spam in vdr.log). Stream-Kette: DVB-C/Kabel an CineCTv6 STV0367@ddbridge, Entschlüsselung via cxd2099 Flex am ngene Expansion Port. EDIT: MTD mit zwei Services auf unterschiedlichen Muxen (1x Playback, 1x Record) funktioniert sauber.

    Moin,


    ich hab jetzt hier 'ne

    Code
    1. [ 112.602687] nGene PCIE bridge driver, Copyright (C) 2005-2007 Micronas
    2. [ 112.602788] ngene: Found Linux4Media cineS2 DVB-S2 Twin Tuner (v5)
    3. [ 112.605245] ngene: Device version 1
    4. [ 112.605290] ngene: Loading firmware file ngene_18.fw.
    5. PCI ID: 18c3:0720 (rev 01) Subsystem: 18c3:dd00

    in der Bastelkiste stecken. Die Onboard-Tuner haben offenbar keine Lust (No STV0900 found - ist das irgendwie fixbar, z.b. durch neuere Firmware, oder hat die Karte dann 'ne Macke? Anderen PCIe Slot schon probiert, mit/ohne Stromversorgung, mit/ohne angeklemmtes Addon; Ein Test mit Windows wird definitiv nicht passieren! EDIT: Spontane Selbstheilung oder Fix durch passende I2C Caps im Adapter? Die zwei STV090x sind jetzt plötzlich da...), mein CXD2099 wird aber erkannt, meldet ein gestecktes ACL R2.2@One4All2.4 und ich kann im CAM Menü (gnutv, VDR UI) rumspielen.


    TVH+DDCI bringt aber so ziemlich gar keinen Output, VDR+DDCI kotzt sich mit "ERROR: invalid MTD number (31) in PID 8191 (1FFF)" im VDR Log aus, aber zumindest gibts am VNSI-Client (Kodi) Pixelmatsch mit Andeutungen von 'nem entschlüsselten Bild. Ich vermute, dass die "Rückfilterei" in tsin_exchange() nicht das tut, was sie soll. Ich hab' im Moment nicht wirklich Zeit (und auch nicht wirklich Lust; ich will die Karte bzw. die Treiber lediglich mit neueren Flexmodulen - STV C/T, CXD C2T2, ggf. DuoFlex S2 V4, das muss aber wer gegentesten) kompatibel machen. Wenn sich jemand mit dem Code beschäftigen mag und Dinge getestet haben möchte, kann der/diejenige mir aber gerne Patches zukommen lassen, ich kann das dann zwischendurch testen.

    Das funktioniert - unter Linux - definitiv problemlos. Genau genommen kannst Du alles (PCIe Bridges, PCIe Bridges mit Tunern oder CI Slots, DuoFlex Module beliebig auf die Bridges verteilt; Im Dev-System hab ich selber 'ne CTv6 und 'ne OctoCIDuo mit 'nem Wildwuchs an Flexmodulen am laufen) mischen, wie Du willst.


    Was Windows angeht: Offen gesagt, keine Ahnung.

    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

    fnu Danke!

    Honker Es wäre mal interessant, was sich in Deinem Kernel-Log abspielt, wenn Dein VDR Probleme bekommt (da wird Dich der DD-Support garantiert auch nach fragen). Ich würde das mit dddvb (hast Du schon installiert) nochmal reproduzieren und das dann dem Support mitteilen.


    Nebenbei, statt

    Mit den neusten Treibern habe ich aber zumindest kein

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

    mehr im Log

    kommt halt jetzt

    Code
    1. [ 5.413137] lnbh25: i2c_write error
    2. [ 5.414410] LNBH25 on 08

    was so ziemlich denselben Hintergrund hat :-) Bitte - gilt auch für alle anderen Mitleser - den Firlefanz einfach ignorieren.


    EDIT: Formatierung.

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

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

    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.

    das ist jetzt evtl ne ganz dumme frage - aber wie installiere ich "ein für Stretch vorgesehenes 4.14er Kernel Package." ?

    Laut Google bzw. packages.debian.org gibts das in stretch-backports, buster oder sid. Frag mich aber jetzt nicht, wie Du das am besten mit Deiner Installation bzw. Deiner Distro abwickelst (ausser .deb's runterladen und mit dpkg -i installieren), ich benutze selber nichts Debian-basiertes. Im Zweifelsfall: http://support.digital-devices…ledgebase.php?article=151


    Zudem habe ich evtl einen Denkfehler - ich habe hier ja schon den 4.9er Kernel - soll ich zum 4.14er downgraden ?

    4.14 > 4.9

    Debian Stretch (ganz frisch mit 4.9er Kernel

    Wenn Du auf der Kernel Version nicht entweder das Treiberpackage von DD selbst installierst oder eines der zahlreichen DKMS-Packages in Dein System verpflanzt (Hint: Jasmins media-build-dkms), kommst Du damit nicht weit. Mein Ratschlag: Lass' das gebastel und installier Dir ein für Stretch vorgesehenes 4.14er Kernel Package.

    Du brauchst nichts gesondert konfigurieren. Einfach Octopus CI Duo Bridge oder DuoFlex CI Addon einbauen. Ab Kernel 4.14 brauchst Du keine Out-of-Tree-Treiber installieren, da ist alles drin, ansonsten eins der zahlreichen DKMS-Packages oder direkt die Treiber von Digital Devices installieren. Dann Karte ins CAM und das CAM in den CI Slot. VDR mit DDCI2-Plugin (und jüngst auch TVHeadend - hier nur den Adapter in den Inputs aktivieren, minisatip ist in Vorbereitung) machen alles andere alleine. Und es ist egal, ob Dein DVB-Signal von einem DD-Tuner oder von was ganz anderem kommt (andere PCI(e) Karte, USB-Stick, SAT>IP). VDR macht zusätzlich MTD, d.h. Du kannst mehr als einen Sender parallel durch das CAM entschlüsseln lassen, sofern das CAM das unterstützt.

    Irgendwas passt da bei Dir nicht:

    Code
    1. $ modinfo ddbridge
    2. version: 0.9.31intermediate-integrated
    3. $ modinfo cxd2841er
    4. author: Sergey Kozlov <serjk@netup.ru>, Abylay Ospan <aospan@netup.ru>
    5. description: Sony CXD2837/38/41/43/54ER DVB-C/C2/T/T2/S/S2 demodulator driver

    Stock-Treiber aus 4.14(.7). w_scan auf 2854er Frontend mit Unitymedia am Antenneneingang:

    Gleiches Ergebnis, wenn die Antenne an der CineCTv6 am STV0367 Demod hängt, dauert nur länger, weil der Demod bzw. der Treiber kein QAM_AUTO unterstützt und daher separat auf QAM64 und QAM256 gescannt wird.

    Bei 4.14+ und den Karten in Deiner Sig mach besser

    Code
    1. apt-get --purge remove dddvb-dkms

    und erspar' Dir in Zukunft derartige Probleme. Seit 4.14rc1 (für die CT/CT2/C2T2/C2T2I sogar 4.13rc1) ist alles für die DD-Karten in Mainline enthalten.

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