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

    Zitat von sewn4

    das powarman Repo ist down?

    Wenn Du http://powarman.dyndns.org/hg/v4l-dvb-saa716x meinst - hier geht es derzeit.


    Ich wollte gerade media_build_experimental aktualisieren und bekomme nach Aufruf von make folgende Fehler bei den Patches:



    Es handelt sich um Revison 85 - die alte Revision 53 baut ohne Probleme - irgendwelche Ideen?


    Marcus

    My VDRs:

    Zitat von S:oren

    Ich haette auch noch andere Problemchen und Aenderungsvorschlaege fuer den Treiber, sind solche patches hier erwuenscht oder soll ich die lieber woanders hin (oder ueberhaupt nicht) schicken?


    Leider gab es keine Antwort auf die Frage. Auch sonst scheint sich momentan leider niemand um den Treiber fuer die S2-6400 zu kuemmern, was besonders aergerlich ist, weil er nicht im kernel drin ist. Da ich aber hier gebeten wurde, einen weiteren patch zu posten, mache ich das mal: saa716x-workqueue.hg.diff
    Der patch konvertiert das fifo_worker-Tasklet in einen workqueue-Thread, was dann zu deutlich stabilerem Verhalten auf einer langsamen cpu (Marvell Kirkwood) fuehrt. Weitere Erklaerungen gibt es auch in dem verlinkten Thread.


    Gruss,
    S:oren


    Edit: Dieser Patch hat moeglicherweise Probleme auf Multicore-CPUs. Also bitte mit Vorsicht benutzen und im Zweifel auf ein Update warten...
    Edit2: neue Version des Patches hier

    Zitat von S:oren


    Leider gab es keine Antwort auf die Frage.


    Auch ich habe lange nichts mehr von powarman gehört.


    Allerdings könnte ich völlig verstehen, wenn er keine Lust mehr hat. Wer möchte sich schon jedes Mal, wenn er hier ins VDR-Portal schaut, ärgern, weil irgendwelche Dummschwätzer das Projekt, in das man jede Menge Arbeit gesteckt hat, niedermachen?
    So etwas braucht man nicht...


    Zitat


    Auch sonst scheint sich momentan leider niemand um den Treiber fuer die S2-6400 zu kuemmern, was besonders aergerlich ist, weil er nicht im kernel drin ist. Da ich aber hier gebeten wurde, einen weiteren patch zu posten, mache ich das mal: saa716x-workqueue.hg.diff
    Der patch konvertiert das fifo_worker-Tasklet in einen workqueue-Thread, was dann zu deutlich stabilerem Verhalten auf einer langsamen cpu (Marvell Kirkwood) fuehrt. Weitere Erklaerungen gibt es auch in dem verlinkten Thread.


    Bin mir nicht so sicher, ob das Ersetzen des Tasklets durch eine Workqueue immer eine gute Idee ist. Tasklets kommen schneller dran als als eine Workqueue, bei letzterer könnte es also eher zu einem Buffer Overflow kommen. Sollte sich allerdings eher auf langsamen Maschinen auswirken. (Alles reine Theorie, habe gerade keine Zeit, herumzuprobieren...)


    Außerdem können sich natürlich die unterschiedlichen Architekturen von ARM und PC auswirken.
    Afaik wurde der Treiber bisher nie auf ARM getestet.


    CU
    Oliver

    Zitat von UFO

    Auch ich habe lange nichts mehr von powarman gehört.


    Allerdings könnte ich völlig verstehen, wenn er keine Lust mehr hat. Wer möchte sich schon jedes Mal, wenn er hier ins VDR-Portal schaut, ärgern, weil irgendwelche Dummschwätzer das Projekt, in das man jede Menge Arbeit gesteckt hat, niedermachen? So etwas braucht man nicht...


    Full-Ack. Ihr habt beide in diese (und andere) Entwicklungen richtig viel Zeit und Kraft gesteckt. Da ist es wirklich nicht angemessen, darueber zu schimpfen, insbesondere ohne neue Erkenntnisse einzubringen oder irgendwelche konstruktiven Beitraege zur Problemloesung zu leisten. Andererseits gibt es ja keine Herstellertreiber oder andere in-kernel-Treiber zur S2-6400, da verlassen sich halt viele Leute auf die Treiberentwicklung hier. Wenn dann ohne Erklaerung und Perspektive ein paar Monate nichts (oeffentliches) passiert, ist das fuer die Anwender auch frustrierend. Ein "das ist was fuer lange Winterabende", wie hier irgendwo weiter vorne in einem anderen Zusammenhang, hilft da einfach schon. Es gibt sicher viele Anwender, die einfach mitlesen und auf Neuigkeiten hoffen, ohne die Laenge des Threads unnoetig zu vergroessern.


    Zitat

    Bin mir nicht so sicher, ob das Ersetzen des Tasklets durch eine Workqueue immer eine gute Idee ist. Tasklets kommen schneller dran als als eine Workqueue, bei letzterer könnte es also eher zu einem Buffer Overflow kommen. Sollte sich allerdings eher auf langsamen Maschinen auswirken. (Alles aber reine Theorie, habe gerade keine Zeit, herumzuprobieren...)


    Ob es immer eine gute Idee ist, weiss ich auch nicht. (Da gibt es ja auch andere Ansichten, d.h. Bestrebungen, tasklets generell aus dem kernel zu entfernen.) Ohne den patch habe ich auf dem Kirkwood jedenfalls fast 50% Soft-IRQ-Zeit und kein vernuenftiges scheduling mehr (linux-3.5). Mit dem patch laeuft es viel runder. Das Problem ist einfach, dass die Karte Daten nur in einzelnen 32-Bit-Haeppchen entgegen nimmt, was dann quasi unendlich lange dauert (und lang laufende IRQ-Routinen waren noch nie eine gute Idee). Wenn man dann einen Datenstrom vom Tuner entgegennehmen, einen zum Decoder ausgeben und dann noch ein OSD darstellen will, hilft es nicht, wenn sich ein Tasklet auf Kosten der anderen Sachen vordraengelt. Hast Du irgendwelchen Einblick in das Design der Karte, insbesondere, warum sie nicht mit PCIe-Bursts (und damit auch DMA) zurecht kommt? Wenn man das (im FPGA?) fixen koennte, waere man alle diese Probleme los.


    Gruss,
    S:oren

    Zitat von S:oren


    Ob es immer eine gute Idee ist, weiss ich auch nicht. (Da gibt es ja auch andere Ansichten, d.h. Bestrebungen, tasklets generell aus dem kernel zu entfernen.) Ohne den patch habe ich auf dem Kirkwood jedenfalls fast 50% Soft-IRQ-Zeit und kein vernuenftiges scheduling mehr (linux-3.5). Mit dem patch laeuft es viel runder. Das Problem ist einfach, dass die Karte Daten nur in einzelnen 32-Bit-Haeppchen entgegen nimmt, was dann quasi unendlich lange dauert (und lang laufende IRQ-Routinen waren noch nie eine gute Idee). Wenn man dann einen Datenstrom vom Tuner entgegennehmen, einen zum Decoder ausgeben und dann noch ein OSD darstellen will, hilft es nicht, wenn sich ein Tasklet auf Kosten der anderen Sachen vordraengelt. Hast Du irgendwelchen Einblick in das Design der Karte, insbesondere, warum sie nicht mit PCIe-Bursts (und damit auch DMA) zurecht kommt? Wenn man das (im FPGA?) fixen koennte, waere man alle diese Probleme los.


    Habe mir das ganze mal kurz angeschaut: Mir war nicht bewusst, daß der fifo_worker keinen DMA benutzt. Das Schreiben einzelner Worte ist natürlich extrem ineffizient und sollte nicht in einem Tasklet gemacht werden.


    Eine Workqueue ist allerdings auch nur eine Behelfslösung, um das Problem etwas zu entschärfen.
    Am besten wäre es, den Transfer zur Karte auf DMA umzustellen. Die umgekehrte Richtung (demux_worker) verwendet DMA.


    Ob es da ein prinzipielles Problem gibt, müßte Andreas beantworten. Die Interna des FPGA kenne ich nicht.
    Treiberseitig sehe ich kein Problem.


    CU
    Oliver

    Zitat von UFO


    Habe mir das ganze mal kurz angeschaut: Mir war nicht bewusst, daß der fifo_worker keinen DMA benutzt. Das Schreiben einzelner Worte ist natürlich extrem ineffizient und sollte nicht in einem Tasklet gemacht werden.


    Eine Workqueue ist allerdings auch nur eine Behelfslösung, um das Problem etwas zu entschärfen.
    Am besten wäre es, den Transfer zur Karte auf DMA umzustellen. Die umgekehrte Richtung (demux_worker) verwendet DMA.


    Das Problem ist aber nicht der PCI-Transfer. Das Hauptproblem ist, daß das DVB-Demultiplexing in einem Tasklet gemacht wird. Das ist bei großen Paketen tödlich für Single-Core's. Der Treiber gehört mal aufgeräumt!!


    Gruß
    e9hack

    Zitat von S:oren

    Der patch konvertiert das fifo_worker-Tasklet in einen workqueue-Thread, was dann zu deutlich stabilerem Verhalten auf einer langsamen cpu (Marvell Kirkwood) fuehrt. [...]
    Edit: Dieser Patch hat moeglicherweise Probleme auf Multicore-CPUs. Also bitte mit Vorsicht benutzen und im Zweifel auf ein Update warten...


    Hier ist das versprochene Update, damit sollte es auch auf Multicore-CPUs funktionieren. Vielen Dank an Uwe fuer den Bugreport und das Testen der neuen Version!


    Gruss,
    S:oren

    Zitat von S:oren


    Hier ist das versprochene Update, damit sollte es auch auf Multicore-CPUs funktionieren. Vielen Dank an Uwe fuer den Bugreport und das Testen der neuen Version!


    Funktioniert dies auch noch bei mehren Karten im System? Können mehrere Workqueues den gleichen Namen haben?


    CU
    Oliver

    Bei mir läd der Treiber beim booten nicht richtig, ein erneutes rmmod ngene &&modprobe ngene bringt ihn aber zum laufen.


    System ist ein lfs. Kernel 3.5.4, udev-189, ngene Treiber aus dem Kernel werden verwendet.


    dmesg Auszug aus dem Bootvorgang:

    Code
    [   38.061780] ngene: Loading firmware file ngene_18.fw.
[   38.093057] cxd2099_attach: driver disabled by Kconfig
[   38.094272] DVB: Unable to find symbol stv090x_attach()
[   38.094273] ngene: No STV0900 found!
[   38.094280] DVB: Unable to find symbol stv090x_attach()
[   38.094281] ngene: No STV0900 found!
[   38.112501] No demod found on chan 2
[   38.130240] No demod found on chan 3


    dmesg Auszug nach rmmod ngene &&modprobe ngene


    Edit: Zusätzlich habe ich gerade noch bemerkt das mir der Treiber den Bootvorgang um 30 Sekunden verzögert, ich hab dafür gerade mal testweise die ngene.ko verschoben, so dass diese beim Bootvorgang nicht gefunden wird. Gibt es die Möglichkeit hier mitzuloggen was hier passiert? Die 30 Sekunden sehen mir sehr nach einem Timeout aus.


    Auszug ohne ngene.ko

    Code
    [    7.666010] input: HDA NVidia HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1/input14
[    7.677098] vgaarb: device changed decodes: PCI:0000:01:00.0,olddecodes=io+mem,decodes=none:owns=io+mem
[    7.687152] NVRM: loading NVIDIA UNIX x86 Kernel Module  304.51  Tue Sep 18 17:36:24 PDT 2012
[    8.302498] EXT3-fs (sdb1): using internal journal
[    9.300173] r8169 0000:07:00.0: eth0: unable to load firmware patch rtl_nic/rtl8168e-2.fw (-2)
[    9.333719] r8169 0000:07:00.0: eth0: link down


    Auszug mit ngene.ko

    Zitat von S:oren


    Gute Frage, kann ich leider nicht testen.


    Ich habe nichts gefunden, dass es nicht funktionieren soll. Aber trotzdem schadet ja auch nicht, eine Device-Nummer mit anzugeben. Allerdings funktioniert diese Syntax erst in neueren Kernels. Eine neue Patchversion habe ich angehaengt.



    Zitat von UFO

    Habe mir das ganze mal kurz angeschaut: Mir war nicht bewusst, daß der fifo_worker keinen DMA benutzt. Das Schreiben einzelner Worte ist natürlich extrem ineffizient und sollte nicht in einem Tasklet gemacht werden.


    Eine Workqueue ist allerdings auch nur eine Behelfslösung, um das Problem etwas zu entschärfen.
    Am besten wäre es, den Transfer zur Karte auf DMA umzustellen. Die umgekehrte Richtung (demux_worker) verwendet DMA.


    Ob es da ein prinzipielles Problem gibt, müßte Andreas beantworten. Die Interna des FPGA kenne ich nicht.
    Treiberseitig sehe ich kein Problem.


    Ich habe leider nirgends gefunden, ob (und wenn ja wie) der SAA7160 DMA auch zum PHI-Bus unterstuetzt. Hat jemand ein SAA7160-UserManual, oder einen anderen Tipp fuer mich?


    Gruss,
    S:oren

    Hallo,


    das ist kein Wunder. In den neueren udev Versionen ist das Verhalten zum laden der Modul-Firmwares geändert worden. Der Treiber müsste darauf angepasst werden.
    Ich weiß nicht, ob das hier schon geschehen ist. Sieht aber danach aus.


    Gruss, Thomas

    Zitat von UFO

    Da Mauro gerade die gesamte v4ldvb-Directory-Struktur durcheinanderwürfelt und daher nichts mehr kompiliert, habe ich den Upstream-Treiber auf den Stand vom 13.8.2012 eingefroren. Ich werde dies erst rückgängig machen, wenn sich die neue Struktur stabilisiert hat und Upstream wieder kompiliert. Schätze Anfang September... ;(


    CU
    Oliver


    Gibt es hierzu etwas Neues, oder ist es immernoch eingefroren?

    Zitat von tomglx

    Hallo,


    das ist kein Wunder. In den neueren udev Versionen ist das Verhalten zum laden der Modul-Firmwares geändert worden. Der Treiber müsste darauf angepasst werden.
    Ich weiß nicht, ob das hier schon geschehen ist. Sieht aber danach aus.


    Nein, ist er nicht.


    Mir ist nicht klar, wie das überhaupt funktionieren soll. ngene ist schließlich eine PCIe-Bridge, die ohne aktuelle Firmware nicht richtig funktioniert. Wie soll die Hardware initialisiert werden, wenn die Bridge nicht funktioniert?


    Die imho einzig sinnvolle Vorgehensweise wäre, das Laden des Treibers zu verschieben, bis die Firmware in den Kernel geladen ist. Für so etwas gibt es afaik jedoch keine Infrastruktur.


    Ich werde abwarten, wie sich das ganze entwickelt. Das Problem wird hoffentlich(!) massiv bei anderen Kerneltreibern auftreten. Falls sich da nichts tut, werde ich die Firmware wieder - wie früher - in den Treiber einkompilieren.


    CU
    Oliver

    Zitat von C-3PO


    Gibt es hierzu etwas Neues, oder ist es immernoch eingefroren?


    Upstream media_build ist nach wie vor unbrauchbar, vgl. Postings "cron job: media_tree daily build: ERRORS" auf der ML.
    Solange sich dies nicht ändert, fange ich gar nicht erst mit den Anpassungen an...


    CU
    Oliver


    Danke für die Info warum es nicht funktioniert. Als Workaround sitzt bei mir ngene jetzt auf der Blacklist und wird später durch ein init-Script geladen. Ist zwar nicht wirklich der schönste Weg, aber funktioniert erstmal.

    Zitat von S:oren


    Ich habe nichts gefunden, dass es nicht funktionieren soll. Aber trotzdem schadet ja auch nicht, eine Device-Nummer mit anzugeben. Allerdings funktioniert diese Syntax erst in neueren Kernels. Eine neue Patchversion habe ich angehaengt.


    Hm - wieso eigentlich eine Workqueue pro Karte? Eine einzige Workqueue für alle Karten täte es doch auch?


    Zitat


    Ich habe leider nirgends gefunden, ob (und wenn ja wie) der SAA7160 DMA auch zum PHI-Bus unterstuetzt. Hat jemand ein SAA7160-UserManual, oder einen anderen Tipp fuer mich?


    Habe nachgelesen und wenn ich mich nicht täusche, kann der saa7160 tatsächlich keinen DMA in Richtung PHI. Bleibt also nur die Workqueue.


    Btw, könnte es sein, daß http://linuxtv.org/hg/~endriss/mirror-saa716x nicht auf dem letzten Stand ist? (Powarman's Repository ist seit einiger Zeit nicht erreichbar.) Ich bekomme mit Deinen Patches nämlich einen - wenn auch trivialen - Reject in saa716x_ff.h.


    CU
    Oliver

    Zitat von UFO

    Hm - wieso eigentlich eine Workqueue pro Karte? Eine einzige Workqueue für alle Karten täte es doch auch?


    Hm, wenn schon jemand zwei Decoderkarten in einem Rechner betreibt, dann hat er doch sicher eine Multicore-CPU und moechte Daten zu beiden Karten gleichzeitig schicken!? Ist ja schon langsam genug.
    Ist sicher ein theoretischer Fall, oder betreibt tatsaechlich jemand mehrere S2-6400 in einem Rechner mit gleichzeitigem Decoderbetrieb?


    Zitat

    Habe nachgelesen und wenn ich mich nicht täusche, kann der saa7160 tatsächlich keinen DMA in Richtung PHI. Bleibt also nur die Workqueue.


    Hurra, welch "Spitzendesign" von Bridge-Chip und Karte...
    Wenn Busmaster-DMA nicht geht, waere ja aber auch Host-DMA denkbar. (Will man sich den Supportaufwand antun?)


    Zitat

    Btw, könnte es sein, daß http://linuxtv.org/hg/~endriss/mirror-saa716x nicht auf dem letzten Stand ist? (Powarman's Repository ist seit einiger Zeit nicht erreichbar.) Ich bekomme mit Deinen Patches nämlich einen - wenn auch trivialen - Reject in saa716x_ff.h.


    Der workqueue-Patch ist ja der dritte nach diesen hier. Liegt es daran?



    Was anderes: fuer die Ausgabe des TS-Stroms wird ja ein dvb_ringbuffer verwendet. Leider ist der nicht so richtig auf diesen Job angepasst. Momentan werden die Daten mit memcpy reinkopiert obwohl ein copy_from_user angebracht waere (ein Wunder, dass es so stabil laeuft), beim rauskopieren im fifo_worker wird ein an sich unnoetiger Zwischenpuffer verwendet. Sollte man hier den dvb_ringbuffer erweitern oder lieber einen einfachen ts_buffer in den saa716x-Treiber einbauen?


    Gruss,
    S:oren

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden