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

  • Servus VDR-Gemeinde,


    kleine Erklärung zu meinem Problem:
    Ich habe mir vor einiger Zeit eine Cine S2 zugelegt, diese funktionierte auch tadellos. Vor ein paar Monaten bin ich umgezogen und war gezwungen auf Kabel umzusteigen, also habe ich mir eine Cine C/T geholt. Bisher auch keine Probleme damit gehabt. Nun habe ich mir aber noch zusätzlich eine Satschüssel angebracht und wollte die alte Cine S2 zur C/T dazustecken --> Und hier beginnt das Problem, irgendwie hab ich so das Gefühl das die S2 irgend einen Defekt hat. Die C/T rennt weiterhin ganz normal, aber bei der S2 kriege ich im dmesg folgende seltsame Ausgabe:


    Code
    1. [ 8.734948] Digital Devices PCIE bridge driver, Copyright (C) 2010-11 Digital Devices GmbH
    2. [ 8.743395] DDBridge 0000:01:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
    3. [ 8.743413] DDBridge driver detected: Digital Devices Cine S2 V6 DVB adapter
    4. [ 8.743433] HW 00010009 REG 00010004
    5. [ 8.743476] DDBridge 0000:01:00.0: irq 43 for MSI/MSI-X
    6. [ 8.744977] Port 0 (TAB 1): NO MODULE <----- Normalerweise müsste doch hier "Dual DVB-S2" oder so etwas in der Art stehen, richtig?
    7. [ 8.745579] Port 1 (TAB 2): NO MODULE
    8. [ 8.746187] Port 2 (TAB 3): NO MODULE


    Ich habe die Karte dann auch noch einzeln in meinen Testrechner eingebaut, dann "linux-media-dkms" aus dem yavdr-ppa installiert und noch vdr dazu, jedoch ist es dort das selbe Problem.


    Vdr lässt sich natürlich nicht starten, er bringt mir verständlicher weise folgende Meldung:


    Code
    1. vdr: [1107] no DVB device found
    2. runvdr: stopping after fatal fail (vdr: no primary device found - using first device!)


    Hat jemand eine Idee? Wie gesagt, die Karte lief bis vor ca. nem dreiviertel Jahr einwandfrei, seitdem hat sie die Zeit nur in der Verpackung verbracht.
    Oder hat sich inzwischen die Prozedur irgendwie geändert, das die Treiber anders installiert werden müssen als früher? Ich habe mich nämlich schon länger nicht mehr damit beschäftigt, da ich bis jetzt keine Probleme damit hatte.

  • Am Treiber kann es nicht liegen. Datenkabel falsch aufgesteckt oder fehlende Stromversorgung?

  • Ok, ich dachte, Du hättest eine DuoFlex...


    In diesem Fall braucht's i.d.R nicht einmal ein Stromkabel.


    Wird die Karte von "lspci -vnn" angezeigt?
    Falls nein, anderen PCIe-Slot versuchen bzw. nachsehen, ob sie auch richtig im Slot steckt.


    CU
    Oliver

  • lspci gibt folgende Ausgabe:


    Code
    1. 01:00.0 Multimedia controller [0480]: Digital Devices GmbH Octopus LE DVB adapter [dd01:0003]
    2. Subsystem: Digital Devices GmbH Device [dd01:0020]
    3. Flags: bus master, fast devsel, latency 0, IRQ 43
    4. Memory at fdff0000 (64-bit, non-prefetchable) [size=64K]
    5. Capabilities: [50] Power Management version 3
    6. Capabilities: [70] MSI: Enable+ Count=1/2 Maskable- 64bit+
    7. Capabilities: [90] Express Endpoint, MSI 00
    8. Capabilities: [100] Vendor Specific Information: ID=0000 Rev=0 Len=00c <?>
    9. Kernel driver in use: DDBridge
    10. Kernel modules: ddbridge


    ich hab schon alle slots ausprobiert, bringt nichts


    ich werde sie wohl zurückschicken müssen, Garantie sollte noch drauf sein...


  • Nur mal langsam, die Karte wird ja angezeigt. Was steht im Log vom Laden des Treibers?

  • Hallo,
    habe jetzt das System komplett neu aufgesetzt (um Doppeldateien zu vermeiden bzw. versch. Versionen der Treiber).
    Zusätzlich bin ich der Anmerkung auf Seite 1 gefolgt hinsichtlich des MEDIA Ordners.
    Folgendes Problem: der LIRC_TTUSBIR Treiber bzw. das Modul wird nicht geladen.
    Diese Meldung in DMESG:

    Code
    1. root@easyVDR:~# dmesg | grep lirc
    2. [ 6.774176] lirc_dev: IR Remote Control driver registered, major 249
    3. [ 6.777541] rc rc0: lirc_dev: driver ir-lirc-codec (ttusbir) registered at minor = 0
    4. [ 8.838943] lirc_ttusbir: disagrees about version of symbol lirc_register_driver
    5. [ 8.838956] lirc_ttusbir: Unknown symbol lirc_register_driver (err -22)
    6. [ 8.846854] lirc_ttusbir: disagrees about version of symbol lirc_register_driver
    7. [ 8.846868] lirc_ttusbir: Unknown symbol lirc_register_driver (err -22)
    8. [ 8.925979] init: easyvdr-inputlirc main process (977) killed by TERM signal
    9. [ 8.945386] init: lircd main process (1011) killed by TERM signal
    10. [ 8.947911] init: lircd-transmitter main process (1014) killed by TERM signal


    Wenn ich versuche das Modul manuell zu laden kommt das hier:

    Code
    1. root@easyVDR:~# modprobe lirc_ttusbir
    2. FATAL: Error inserting lirc_ttusbir (/lib/modules/3.0.0-19-generic/updates/dkms/lirc_ttusbir.ko): Invalid argument


    Wenn ich das alles richtig recherchiert habe dann passt die Treiberdatei nicht mehr zum Kernel.
    Wie gehe ich jetzt vor um das reparieren?
    Muss ich LIRC neu kompilieren und installieren?


    Komplettes DMESG anbei

  • ricci2407


    Der ttusbir-Treiber findet sich bei Verwendung media_build_experimental afaik seit einem der letzten Updates unter staging-drivers / Linux Infrared Remote Control ..., d.h. er gehört zu rc-core.


    Lirc brauchts damit dann gar nicht mehr, aber u.a. eine passende keymap unter /etc/rc_keymaps.


    Ich habe die ttusbir jetzt mit dem remote-plugin von UFO (Danke!) als

    Code
    1. -P'remote -i /dev/input/event2'


    eingebunden.


    Es geht auch mit inputlircd oder eventlircd, aber damit habe ich zur Zeit noch Probleme mit der Tastenwiederholung bei meiner Harmony.


    Grüße, Peter

    KODI, tvh, arch x86_64, Octopus net 2 x Duoflex C/C2/T2 , NUC7i3BNH, Crucial MX300 2TB, LG LM 669S

    Linux is the best OS I have ever seen -- Albert Einstein


  • Ich tendiere allerdings dazu, das Problem auf andere Weise zu lösen:
    Man sollte erst gar keine sys-Files anlegen, welche die Karte nicht unterstützt. Ich muß das aber noch mit dem Treiber-Entwickler abstimmen.


    Das wird nicht leicht bei der derzeitigen Treiber Struktur.
    Man kann zwar SysFS Knoten dynamisch anlegen, aber der Treiber ist derzeit nicht so geschrieben.
    Es wird mit statischen Tabellen gearbeitet, was 90% der Linux Treiber so machen. Zumindest die,
    die ich analysiert, bzw. geschrieben habe. Ich habe aber auch schon die dynamische Variante verwendet
    und auch schon damit getrickst (Sudir von Subdir mit generic Kernel Funktion anlegen).


    Angesichts dieser Tatsache und wg. dem nötigen Aufwand, der andernorts besser eingesetzt wäre,
    würde ich den Treiber so lassen und es eben in der einen Funktion abfangen. Natürlich wäre es schöner
    nur die Attribute anzulegen, die es pro Karte auch gibt.
    Das könnte man auch mit statischen Attribut Tabellen erreichen, wenn man für jede Karte diese Attribut
    Tabellen anlegen würde. Ähnlich den ddb_info Strukturen. Da könnte man den Pointer auf die jeweiligen
    SysFS Attribute dazu geben.
    Diese Lösung wäre nicht so aufwändig. Kann man in ca. 4 Stunden Programmieren, wenn man weiß,
    welche Karte welche Attribute verwendet.
    Man könnte auch die Zählenden Attribute (led, mod, snr) mit 4 statischen Tabellen anlegen und jeder Port
    verwendet eine andere. Alle anderen Attribute einmal mit der bereits existierenden Tabelle. Dann würde
    zwar bei der CineS2 auch ein temp erzeugt werden, was aber nicht schlimm ist.


    Andererseits geht der Treiber mit meinem Patch auch und man weiß ja nie welche User Mode Programme
    welche Attribute bereits verwenden. Das Kernel Interface zu ändern ist nie eine gute Idee. Ich muss da
    immer viel Argumentieren, wenn ich das mache. Da wird eher Zeit/Code in die Abwärtskompatibilität
    investiert. Es so zu belassen hat auch denn Vorteil, dass man in Zukunft mal tatsächlich einen SNR Wert
    auslesen kann, wenn er von der Karte bereit gestellt wird.


    Wenn ich es zu entscheiden hätte würde ich den Patch verwenden, ein inline dazu schreiben und die
    Attribute so belassen, weil das nur 15 Minuten Aufwand bedeutet :D

  • ähm...wo genau finde ich denn das Log vom laden des Treibers? Bzw. was genau soll ich hier reinposten?


    Ausgabe von "dmesg" als Anhang hochladen. (Wie es andere hier auch machen. Lest ihr eigentlich nicht, was andere posten?)


  • Ich habe einen Patch angehängt, wie ich mir das so vorstelle. Einziges Problem könnte sein, daß die Dateien erst nach device_create angelegt werden, d.h. udev bekommt die neuen Files nicht mit. Andererseits geht udev das auch nichts an.


    Afaik sind alle sys-ddbridge-Files - mit Ausnahme von "redirect" - undokumentierte Debugfeatures. Auf diese Schnittstellen kann sich niemand berufen...


    CU
    Oliver

  • Ich habe einen Patch angehängt, wie ich mir das so vorstelle. Einziges Problem könnte sein, daß die Dateien erst nach device_create angelegt werden, d.h. udev bekommt die neuen Files nicht mit.


    Nun ja, ports und redirect sind beim Erzeugen des Devices da (Attribute der Class). Derzeitige UDEV Regeln benutzen nur redirect, soweit ich weiß. Also ist das mal kein Problem.


    Ich habe mir den Patch nur angesehen und noch nicht gepatched, aber das wird sicher so funktionieren, wie du dir das vorstellst.
    Ich mache auch immer eine Cleanup Funktion, was man hier aber vielleicht nicht muss, weil das ganze Directory beim Device entfernen gelöscht wird. Muss ich aber erst ausprobieren, wenn ich den Patch teste. Soweit ich mich an die Kernel Implementierung erinnere erzeugt die das Directory und dann die Files die in der device_attribute Struktur stehen. Beim Löschen wird auch File für File gelöscht und dann erst das Directory und dann würden die dynamisch erzeugten Files übrig bleiben. Aber vielleicht ist das im 3.x Kernel anders, als im 2.6.x. Ich werde es ja beim Modul Entladen merken. Wenn notwendig schreibe ich die Uninit Funktion.
    Komme aber heute nicht mehr zum Testen :sleep


    LG
    Jasmin


  • Nun ja, ports und redirect sind beim Erzeugen des Devices da (Attribute der Class). Derzeitige UDEV Regeln benutzen nur redirect, soweit ich weiß. Also ist das mal kein Problem.


    Btw, ddbridge0 wird ohnehin nach den /dev/dvb/adapter... Files erzeugt. D.h wenn es ein Race gibt, dann war das schon immer so...


    Quote


    Ich habe mir den Patch nur angesehen und noch nicht gepatched, aber das wird sicher so funktionieren, wie du dir das vorstellst.
    Ich mache auch immer eine Cleanup Funktion, was man hier aber vielleicht nicht muss, weil das ganze Directory beim Device entfernen gelöscht wird. Muss ich aber erst ausprobieren, wenn ich den Patch teste. Soweit ich mich an die Kernel Implementierung erinnere erzeugt die das Directory und dann die Files die in der device_attribute Struktur stehen. Beim Löschen wird auch File für File gelöscht und dann erst das Directory und dann würden die dynamisch erzeugten Files übrig bleiben. Aber vielleicht ist das im 3.x Kernel anders, als im 2.6.x. Ich werde es ja beim Modul Entladen merken. Wenn notwendig schreibe ich die Uninit Funktion.


    Nach dem Entladen des Moduls ist alles (Files + Directories) weg. Der Kernel räumt also auf.


    CU
    Oliver

  • ... Damals (Febr. 2012) noch mit dem media_build_experimental gebaut und dem 3.2.1er Kernel, funktioniert mein System richtig gut und stabil:


    Hier noch mal die Frage, ob es eine "Übersetzung" gibt, die mir sagt, welche Version der Entwicklung in welche Kernelversion geflossen ist?


    Bspw:

    Code
    1. linux-2.6.39 --> vom 31.12.2011
    2. linux-3.2.1-r2 --> vom 14.04.2012
    3. linux-3.6.11 --> vom 3.11.2012

    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

  • Quote

    Du musst die staging Treiber vom media_build aktivieren

    3PO : dort gibt es aber kein LIRC_TTUSBIR. Es gibt eins unter: Multimedia Support --> Remote Controller devices --> Technotrend USB IR Receiver, das heisst aber: IR_TTUSBIR.
    Heisst das wenn ich die Staging Treiber aktiviere, funktioniert LIRC?
    Edit: habe ich jetzt gemacht. Leider mit der gleichen Fehlemeldung. Was kann ich tun damit es funktioniert?

    @lostinspc: ich brauche aber LIRC, da hängen bei EASYVDR einige Programme dran. U.a. der Programm Changer.


    Grüsse
    Ricci


  • ich brauche aber LIRC, da hängen bei EASYVDR einige Programme dran. U.a. der Programm Changer.
    Grüsse
    Ricci


    Bei mir hat der Treiber für ttusbir mit lirc 0.9 und den neueren Kernels nicht mehr gebaut. Daher habe ich dann auf den rc-core Treiber im media-build-experimental gewechselt.


    Der stellt ein input-event unter /dev/input bereit. Entweder man nutzt das input-device direkt, oder man adaptiert es wieder auf ein lirc-device.


    Das geht meiner Meinung nach am einfachsten mit inputlircd, der kann auch parallel zu einer direkten Nutzung von /dev/input/eventX verwendet werden.
    Alternativ geht auch eventlircd oder auch lirc direkt, mit --devinput .


    Du musst dich auf jeden Fall entscheiden, ob Du (sofern möglich) den lirc-Treiber für ttusbir nimmst oder den aus media_build.


    Lesenswert ist auch die yavdr-Doku dazu vom Fernbedienungs-Papst ;-) seahawk86


    Grüße, Peter


    <edit>: Das Thema hat mit dem Thread-Titel nur noch entfernt zu tun, bitte ggfs. einen neuen Thread an passender Stelle aufmachen

    KODI, tvh, arch x86_64, Octopus net 2 x Duoflex C/C2/T2 , NUC7i3BNH, Crucial MX300 2TB, LG LM 669S

    Linux is the best OS I have ever seen -- Albert Einstein

  • Komme aber heute nicht mehr zum Testen :sleep


    Prinzipiell funktioniert der Patch.


    Nach dem Entladen des Moduls ist alles (Files + Directories) weg. Der Kernel räumt also auf.


    Du meintest, der Kernel würde zusammen räumen. Nur weil die SysFS Knoten weg sind, heißt das ja nicht, dass alles palleti ist.
    Ich habe mir die Mühe gemacht und das nachzuwassern :rolleyes:


    ddb_device_destroy ruft device_destroy (drivers/base/core.c) auf.
    device_destroy nach einigen Umwegen dann device_del (.../core.c).
    device_del entfernt die SysFS Attribute, die über die Class definiert wurden. Dieses mit der Funktion device_remove_attrs (.../core.c). device_remove_attrs wiederum verwendet device_remove_attributes (.../core.c) mit den Class Attributen um diese einzeln zu löschen.
    Am Ende von device_del wird dann kobject_del (lib/kobject.c) aufgerufen, welches sysfs_remove_dir (fs/sysfs/dir.c) und dann __sysfs_remove_dir (fs/sysfs/dir.c) aufruft.
    __sysfs_remove_dir geht das Directory durch und löscht die restlichen Einträge, wenn ich das richtig durchgedacht habe. Allerdings bleiben da Directories über, weil die Funktion diese nicht löscht.


    Ich weiß nicht ob ich bei der Analyse etwas übersehen habe, es ist schon spät.
    Aus meiner Sicht ist das ein Notanker "and not indended". Warum sollte die Funktion device_remove_attributes das einzeln machen, wenn sowieso irgendwann das ganze Verzeichnis gelöscht wird?
    Ich denke eher, man sollte SysFS Knoten die man selbst erzeugt, auch brav wieder entfernen und das nicht dem Kernel überlassen, der hier offensichtlich nicht alles löscht, was noch über ist (Directories). Zumindest handhabe ich das in meinen Treibern immer so. Der der etwas erzeugt, ist auch für das Entfernen zuständig. Das gilt bei mir auch für Funktionen. Diese müssen immer symetrisch sein. Also eine Create und eine Delete Funktion, die genau vice versa funktionieren.


    Die einzelnen SysFS Files werden im Übrigen im Kernel Memeory allociert und wenn sie tatsächlich übrig bleiben sollten, dann hat man ein Speicherleck. Zugegeben, diese Module werden normalerweise nur geladen und nicht permanent geladen und entfernt, aber ... .


    Ich habe eine Cleanup Funktion für die Erzeugten SysFS Knoten geschrieben und getestet.
    Weiters das fehlende Fehlerhandling beim Aufruf von ddb_device_create in ddb_probe ergänzt. Falls was schief geht, loggt die Funktion ddb_device_create was passiert ist.
    Außerdem hinterlässt sie dann auch das ddbs Array wieder sauber aufgeräumt.
    Anbei der Patch. Bitte im Originalen File, also ohne deinem ersten Patch anwenden!


    LG
    Jasmin

    Files