Aktuelle Treiber für Octopus(ddbridge), CineS2(ngene/ddbridge), DuoFlex-S2, DuoFlex-CT, CineCT sowie TT S2-6400 (Teil 2)

  • Noch ein Gedanke:
    Ev könnte man prinzipiell das HC Bit setzen und dann erst DA abfragen ... .

    Bringt keine Verbesserung. Mein CI/CAM geht ohne Timeout nicht, egal wie früh ich das HC Bit setze. Also bleibt der Patch wie er ist.
    Mir ist noch aufgefallen, dass das CAM sehr empfindlich reagiert. Der VDR verliert beim Durchblättern durch das Menü manchmal die Verbindung.
    Hast das noch jemand bei seinem CAM?


    Ich werde versuchen das noch weiter zu untersuchen. Sprich ob es das CAM, oder die VDR CI Protokollimplementierung ist.
    Mann ist das mühsam mit dem Teil, zickig wie unsere Sekretärin ;(


    Edit:
    Der VDR knüppelt das CAM nieder (ioctl CA_RESET). Also muss ich doch den VDR CI Code debuggen ... .
    Hat hier wer Erfahrung an der Ecke, oder ist wieder mein Forscherdrang gefragt?


    Kinder, es ist 4:30 Uhr, ich geh' heute auf einen Ball, Schluss für Heute: :n8

    Einmal editiert, zuletzt von jasminj ()

  • Nach einigen Tagen suchen, denken, Kontakt zu L4M, eMails mit dem ursprünglichen Treiber Entwckler austauschen und 2 Nächten ohne Schlaf, habe ich heute beim eMail Scheiben ein lange schlummerndes Problem im CI Protokoll Treiber dvb_ca_en50221.c gefunden.


    Dieser Treiber implementiert das Protokoll, welches in der EN 50221 von 1997 spezifiziert wurde und die PCMCIA Schnittstelle zum CAM beschreibt. Auf nur 2 Seiten von 86, werden dort ein paar Status Bits und Antworten dazu beschrieben.


    Diesen Standard sollte man von hinten nach vorne lesen. ;)



    Möglicherweise ist es auch ein Fehler der CAM-SW:
    Um derartige Races zu vermeiden, müßte das CAM das FR-Bit bereits wegnehmen, wenn es etwas zu senden beabsichtigt, d.h. möglichst bevor es das DA-Bit setzt. Daß Dein Patch hilft, deutet m.E. entweder darauf hin, daß der CXD etwas falsch macht oder das CAM das FR-Bit zu spät löscht.


    Unabhängig davon, welche Rolle der CXD evtl. noch spielt: Wenn zwei Prozessoren gleichzeitig aktiv werden, gibt es Zeitfenster, in denen Daten inkonsistent sein können. Das Protokoll muß dies berücksichtigen. Afaics kann das gleiche mit jedem beliebigen CI - mit geringer Wahrscheinlichkeit - passieren, wenn der Scheduler die CI-Task an der falschen Stelle kurz schlafen legt...



    Der Mutex-Patch ist beim aktuellen Treiberstand von media_build_experimental nicht nötig.


    Er ist Bestandteil eines größeren Patchsets, der - salopp gesagt - den "globalen" Ioctl-Lock entfernt und die Locks "nach unten" schiebt. Natürlich ist der Patchset so gut wie ungetestet, "müßte aber korrekt sein", und wurde deshalb in media_build integriert.


    Bei so etwas gehen bei mir alle Warnlampen an. Dies ist der Grund, weswegen der Upstream-Treiber bei media_build_experimental momentan auf die Version vom 24.12. festgenagelt ist. Diese Änderung ist mir noch zu heiß.



    Dazu hab ich noch was in der Erklärung vergessen:
    Das Protokoll schreibt das HC Bit in das CAM. Das bedeutet für das CAM, dass der Host etwas senden möchte. Danach fragt das Protokoll das Free bit ab, aber nur dieses, und vergisst dabei das DA Bit, mit dem das CAM eine Leseanforderung signalisiert. Das DA Bit hat das Protokoll zwar bereits vorher abgefragt, aber es vergeht eben Zeit zw. dem ersten DA prüfen und dem HC setzen. Also muss man danach noch einmal das DA Bit prüfen, weil erst ein gesetztes HC, weitere DAs verhindert. Dieses zusätzliche Prüfen macht mein Patch, weil das bei jedem CAM vorkommen kann und eine Race condition darstellt.


    Das zusätzliche Prüfen von DA, d.h. Abbruch bei FR==0 oder DA==1, wäre für mich ok.
    Funktioniert es dann auch ohne sleep? Falls ja, ist es imho ein Fehler der CAM-SW, s.o.


    Zitat

    Das glaube ich nicht, dass wir das sollten, weil es eben auch andere HW gibt, wo man den HW Layer nicht in der Hand hat und dann kommt es zu den Problemen, die seit einigen Jahren immer wieder auftauchen. Ev. das Timeout entfernen, aber das DA Bit nach dem HC setzten sollte drinnen bleiben.


    Imho spricht nichts dagegen, die Sache robuster zu machen, indem man DA noch einmal testet.


    Zitat

    Brauchst du das auch schon für yaVDR?
    Für den Trunk ist mir das klar. Ich muss nur erst mit git klar kommen, verwende beruflich nur SVN.
    Und ja, wenigstens ein kleines Sternchen habe ich mir verdient :O


    Der Treiber hier ist für alle, nicht speziell für yaVDR. yaVDR verwende ich selbst nicht.


    Du brauchst kein SCM, um konforme Patches zu schreiben.
    Der ganze Text kommt einfach in die Patch-Datei vor den eigentlichen Diff.


    Zitat


    Noch ein Gedanke:
    Ev könnte man prinzipiell das HC Bit setzen und dann erst DA abfragen. Wenn man eine schnelle HW hat, die direkt auf die CAM Register zugreift, würde das auch gut funktionieren, denke ich, und es wäre SPEC konform, so wie ich sie interpretiere. Muss ich mal bei mir ausprobieren. Vielleicht geht es dann ohne Timout.
    Hey, danke Jungs :tup , jetzt habe ich durch das beschreiben hier eine mögliche Verbesserung meines Patches gefunden. DAS, passiert, wenn man ein Review macht und deshalb steht das alles hier!


    HC setzen ohne vorher DA abzufragen, sollte man nicht tun. Das triggert möglichwerweise irgendwelche Bugs, die bisher verborgen geblieben sind.


    dvb_ca_en50221_write_wait_1.diff werde ich nachher committen, dvb_ca_en50221_mutex.diff nicht.


    CU
    Oliver

  • Moin


    e9hack
    bevor du hier was schreibst, solltest du lesen und nachdenken!
    Das hier ist genau richtige Ort, um auf !!!Deutsch!!! Änderungen an diesem Treiber zu veranlassen.


    Dein Beitrag und die damit zusammen hängenden Beiträge wurden entfernt bzw. editiert!


    Thread wieder offen

    Dirk

    Einmal editiert, zuletzt von Dirk ()

  • Ich hatte mir zwar mal das media_build_experimental reingezogen und zu einem existierenden Kern dazugeschmissen, nachdem aber nicht alles glatt laeuft (siehe andere postings) wuerde ich das gerne als weiteren moeglichen Fehlerfaktor erst mal eliminieren. Deswegen wuerde ich gerne mal als summary wissen:


    A) Wie gut sollte eine Cine S2 V6 plus moegliche Flex-Module mit den ddbridge treibern arbeiten die in vanilla Linux-Kernel drin sind,
    also z.b.: sowas im Bereich 3.1.6 ... 3.7.4 (irgendeine Aussage waere hilfreich). Oder auch: was sollte besser laufen mit dem experimental treiber ?


    B) Ich habe eine V6.5, da habe ich einfach in den Vanilla kernel ins ddbridge-core.c das passende ddb_info und _devinitdata eingetragen, jetzt wird die dann auch mit diesem vanilla Kernel erkannt und scheint zu tun. Gibt es da irgendeinen Grund warum die Antwort auf A fuer die 6.5'er mit vanilla Kern und diesem Fix anders sen sollte ?


    Danke!


  • Der VDR knüppelt das CAM nieder (ioctl CA_RESET). Also muss ich doch den VDR CI Code debuggen ... .
    Hat hier wer Erfahrung an der Ecke, oder ist wieder mein Forscherdrang gefragt?


    Wenn VDR länger als 2 Sekunden (QUERY_REPLY_TIMEOUT) keine Antwort vom CAM bekommt, dann ist ein Reset so ziemlich das Einzige, was er noch machen kann, um das Ganze wieder ans Laufen zu bekommen. Sollte dieser Timeout vielleicht vergrößert werden? Ich meine mich aber zu erinnern, das schonmal probiert zu haben, ohne Erfolg.


    Die CAM-Kommunikation stand meines Erachtens von jeher irgendwie auf tönernen Füßen und es kommt immer mal wieder zu Abbrüchen.
    Ich finde es super, daß sich endlich mal jemand fundiert damit auseinandersetzt. Falls deine Untersuchungen zeigen, daß auch Änderungen in VDRs CI-Code sinnvoll wären, sag bitte Bescheid.
    Ich würde zum Beispiel auch gerne den Fall, daß jemand das CAM oder nur die Smartcard herauszieht, besser erkennen können. Habe dafür aber bisher keine Möglichkeiten gefunden, außer eben den Timeout in der Kommunikation.


    Klaus

  • Ich hatte mir zwar mal das media_build_experimental reingezogen und zu einem existierenden Kern dazugeschmissen, nachdem aber nicht alles glatt laeuft (siehe andere postings) wuerde ich das gerne als weiteren moeglichen Fehlerfaktor erst mal eliminieren. Deswegen wuerde ich gerne mal als summary wissen:


    Dazu zitiere ich mich selbst aus dem ersten Beitrag:


    Zitat


    A) Wie gut sollte eine Cine S2 V6 plus moegliche Flex-Module mit den ddbridge treibern arbeiten die in vanilla Linux-Kernel drin sind,
    also z.b.: sowas im Bereich 3.1.6 ... 3.7.4 (irgendeine Aussage waere hilfreich). Oder auch: was sollte besser laufen mit dem experimental treiber ?


    B) Ich habe eine V6.5, da habe ich einfach in den Vanilla kernel ins ddbridge-core.c das passende ddb_info und _devinitdata eingetragen, jetzt wird die dann auch mit diesem vanilla Kernel erkannt und scheint zu tun. Gibt es da irgendeinen Grund warum die Antwort auf A fuer die 6.5'er mit vanilla Kern und diesem Fix anders sen sollte ?


    Kann man machen. Solange nur DVB-S2 Tuner (stv0900) verwendet werden, dürfte es funktionieren. Für diese Vorgehensweise gibt es von mir allerdings keinen Support.


    CU
    Oliver


  • Wenn VDR länger als 2 Sekunden (QUERY_REPLY_TIMEOUT) keine Antwort vom CAM bekommt, dann ist ein Reset so ziemlich das Einzige, was er noch machen kann, um das Ganze wieder ans Laufen zu bekommen. Sollte dieser Timeout vielleicht vergrößert werden? Ich meine mich aber zu erinnern, das schonmal probiert zu haben, ohne Erfolg.


    Die CAM-Kommunikation stand meines Erachtens von jeher irgendwie auf tönernen Füßen und es kommt immer mal wieder zu Abbrüchen.
    Ich finde es super, daß sich endlich mal jemand fundiert damit auseinandersetzt. Falls deine Untersuchungen zeigen, daß auch Änderungen in VDRs CI-Code sinnvoll wären, sag bitte Bescheid.
    Ich würde zum Beispiel auch gerne den Fall, daß jemand das CAM oder nur die Smartcard herauszieht, besser erkennen können. Habe dafür aber bisher keine Möglichkeiten gefunden, außer eben den Timeout in der Kommunikation.


    Man sollte die Robustheit des CI-Treibers/VDR-CI-Codes testen.
    Dazu könnte man beispielsweise in dvb_ca_en50221_write_data() sporadisch einen künstlichen Fehler einstreuen, um zu testen, ob Fälle wie "status = -EAGAIN; goto exit;" sauber behandelt werden.


    CU
    Oliver

  • Hallo,
    könnte man evtl. diesen Patch, der die Tasten der Fernbedienung für die TT S2-6400 FF optional direkt über das Kernel Input Device auswertbar macht in das media-build-experimental aufnehmen?
    [yaVDR 0.5] Neue DVB Treiber für TT S2-6400 erstellen und installieren


    Ich denke, das würde den Empfänger leichter nutzbar machen, wenn man nicht über das remote-Plugin gehen will (und ein paar yaVDR-Nutzer mit dieser Karte glücklich machen).

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • B) Ich habe eine V6.5, da habe ich einfach in den Vanilla kernel ins ddbridge-core.c das passende ddb_info und _devinitdata eingetragen, jetzt wird die dann auch mit diesem vanilla Kernel erkannt und scheint zu tun. Gibt es da irgendeinen Grund warum die Antwort auf A fuer die 6.5'er mit vanilla Kern und diesem Fix anders sen sollte ?

    Kann man machen. Solange nur DVB-S2 Tuner (stv0900) verwendet werden, dürfte es funktionieren. Für diese Vorgehensweise gibt es von mir allerdings keinen Support.

    Prima. Scheint auch gut zu funktionieren (mal gucken, Tag nicht vor Abend loben). Ja, ich habe nur DVB-S2 Tuner. Wie fliessen denn die Patches in den normalen Kernel zurueck ? Die Erkennung der 6.5'er ohne weitere Patchs sollte man doch schon mal nach upstream schicken, odr ? Scheint dann ja wohl bei Verwendung von nur DVB-S2 keinen Unterschied zu machen gegenueber der 6.0'er, und die ist ja im standardkern unterstuetzt.

  • Und welchen Kernel hast Du konkret?

    VDR-Server: Gentoo (AMD64/Core-i7) / VDR-1.7.23 / Digital Devices Octopus CI & 2xDuoFlex S2 HDTV (Rev. V3)
    VDR-Client: Gentoo (AMD64/Atom-D525) / VDR-1.7.23 / Chieftech & iMON-Pad / ASUSTeK - AT5IONT-I / 4GB-RAM & 65GB-SSD
    Alt: 3xTT-1.5 / linuxtv-dvb-1.1.1 + test_av-1.28 + FW-2622 / vdr-1.3.37 / viele Plugins / LFS-4.1

  • Unter gentoo hab ichs probiert und es geht mit 3.1.6 und 3.7.4 ...


    Das ist gut. Danke. :) Ich bin nämlich Gentoo-Freak. Derzeit noch den 3.5.7 Kernel, werde dann aber mal "aufrüsten".

    VDR-Server: Gentoo (AMD64/Core-i7) / VDR-1.7.23 / Digital Devices Octopus CI & 2xDuoFlex S2 HDTV (Rev. V3)
    VDR-Client: Gentoo (AMD64/Atom-D525) / VDR-1.7.23 / Chieftech & iMON-Pad / ASUSTeK - AT5IONT-I / 4GB-RAM & 65GB-SSD
    Alt: 3xTT-1.5 / linuxtv-dvb-1.1.1 + test_av-1.28 + FW-2622 / vdr-1.3.37 / viele Plugins / LFS-4.1

  • Hallo,
    habe ebenfalls versucht das cam zum funktionieren zu bringen, ist mir leider nicht geglückt. Ich habe mit echo "00 02" > /sys/class/ddbridge/ddbridge0/redirect versucht leider nicht geglückt. Mit dem gnu-tv sehe ich meine Karte und die Infos. Anbei ein LOG.
    Vielleicht hat jemand eine Idee.


    ------------------
    Feb 3 16:58:22 linux-wyeu kernel: [23527.145473] v4l-dvb-saa716x: 4056e0428e4e8b3bdcc530c2ad0b3d511dcedec8 saa716x_ff: Protect reading of the captured video with a mutex.
    Feb 3 16:58:22 linux-wyeu kernel: [23527.145764] Digital Devices PCIE bridge driver, Copyright (C) 2010-11 Digital Devices GmbH
    Feb 3 16:58:22 linux-wyeu kernel: [23527.145798] DDBridge driver detected: Digital Devices Octopus CI single
    Feb 3 16:58:22 linux-wyeu kernel: [23527.145828] HW 00010006 REG 00010002
    Feb 3 16:58:22 linux-wyeu kernel: [23527.145874] DDBridge 0000:01:00.0: irq 54 for MSI/MSI-X
    Feb 3 16:58:22 linux-wyeu kernel: [23527.146601] Port 0 (TAB 1): NO MODULE
    Feb 3 16:58:22 linux-wyeu kernel: [23527.148099] Port 1 (TAB 2): DUAL DVB-C/T
    Feb 3 16:58:22 linux-wyeu kernel: [23527.148101] Port 2 (TAB 3): CI internal
    Feb 3 16:58:22 linux-wyeu kernel: [23527.148450] DVB: registering new adapter (DDBridge)
    Feb 3 16:58:22 linux-wyeu kernel: [23527.150837] stv0367 found
    Feb 3 16:58:22 linux-wyeu kernel: [23527.406003] tda18212dd: ChipID 4724
    Feb 3 16:58:22 linux-wyeu kernel: [23527.406416] tda18212dd: PowerState 01
    Feb 3 16:58:22 linux-wyeu kernel: [23527.530280] DDBridge 0000:01:00.0: DVB: registering adapter 0 frontend 0 (STV0367 DVB-C DVB-T)...
    Feb 3 16:58:22 linux-wyeu kernel: [23527.531186] stv0367 found
    Feb 3 16:58:22 linux-wyeu kernel: [23527.785948] tda18212dd: ChipID 4724
    Feb 3 16:58:22 linux-wyeu kernel: [23527.786378] tda18212dd: PowerState 00
    Feb 3 16:58:23 linux-wyeu kernel: [23528.042755] DDBridge 0000:01:00.0: DVB: registering adapter 0 frontend 0 (STV0367 DVB-C DVB-T)...
    Feb 3 16:58:28 linux-wyeu kernel: [23533.772871] Wrote CA packet for slot 0, connection id 0x0 last_frag:0 size:0x2
    Feb 3 16:58:28 linux-wyeu kernel: [23533.776862] dvb_ca adapter 0: DVB CAM detected and initialised successfully

  • Das zusätzliche Prüfen von DA, d.h. Abbruch bei FR==0 oder DA==1, wäre für mich ok.
    Funktioniert es dann auch ohne sleep? Falls ja, ist es imho ein Fehler der CAM-SW, s.o.

    Nein, ohne Timer geht es nur in 2 von 5 Fällen.


    Du brauchst kein SCM, um konforme Patches zu schreiben.
    Der ganze Text kommt einfach in die Patch-Datei vor den eigentlichen Diff.

    OK, wenn es soweit ist, dann würde ich von dir ein "acked-by" brauchen. An Ralph wende ich mich diesbezüglich noch.


    LG
    Jasmin

  • Ich habe mit echo "00 02" > /sys/class/ddbridge/ddbridge0/redirect versucht leider nicht geglückt.

    Ich vermisse eine sehr entscheidende Zeile im Log:

    Code
    Jan 31 01:41:50 vdrjess kernel: [ 1636.153174] redirect: 00, 02


    Bitte lies dir das noch mal durch und die darauf folgenden Posts.
    Hier findest du eine verbesserte Version vom redirct Programm, dass hier vorgestellt wurde.


    Die UDEV Rule, die das redirect Programm triggert, kommt in eine Datei "99-ddbridge.rules", die du unter /etc/udev/rules.d anlegst (Datei anbei !!!Extension: ".txt" entfernen, Forum lässt keine ".txt" Datei anhängen).


    Das oben erwähnte redirect Programm habe ich bei mir unter /etc/udev abgelegt (meine Rules Datei ist dafür geschrieben).


    LG
    Jasmin

    Dateien

    Einmal editiert, zuletzt von jasminj ()

  • Sorry to say that media_build_experimental fails to compile with linux-3.8 (rc6).


    By fiddling I managed to get the compilation to complete but wouldn't run and unfortunately I have no coding skills at all.


    The problems seem to be in the same area as those fixed by the recent section headers patch if thats any help



    Mike X(

  • Hallo,
    ich frage mich gerade, weshalb meine DD Flex CT Karte an einer ngene-PCIe Bridge so langsam initalisiert wird - durchschnittlich vergehen da gut 10 Sekunden, bis alles bereit ist - ist das normal für die Kombination oder kann man da eventuell noch etwas optimieren?
    System ist ein Arch Linux mit Kernel 3.7.5 und den media-build-experimental Modulen (gestern frisch aus dem Git gebaut) auf einem ASUS A8N-VM CSM (spielt der nForce 430 Chipsatz da evtl. eine Rolle?), Athlon 64 3000+, 1 GB Ram, Geforce 210 512 MB.


    Ob ich die Module und die Firmware (ngene_18.fw und drxk_a3.mc) vor udev aus dem Initramfs oder später regulär durch udev laden lasse, macht zeitlich keinen Unterschied - aber immer gut die Hälfte der Boot-Zeit aus.


    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)


  • HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Keine Ahnung, was da passiert ist - hier nochmal ein dmesg-Auszug, wenn udev die Module lädt:

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!