Hm. Was hat ein ddbridge-Problem mit dem saa716x-Treiber zu tun?
Gruss,
S:oren
Mit einem Standard Gentoo 5.17.0 Kernel gibt es keine Probleme, der hat aber keinen saa716x-Treiber. Daher vemute ich das es an den saa716x Anpassungen seit dem ersten Release vom Kernel 5.16 von dir liegt.
Was soll denn ein unbenutzter saa716x-Treiber fuer eine voellig unabhaengige ddbridge-Karte kaputt machen?
Vielleicht hat ja Gentoo irgendwas gefixt, was an dem mainline-ddbridge kaputt ist? Aber heh, ich weiss es nicht. Kannst ja mal ein git bisect versuchen. Wuerde empfehlen, erstmal mit vanilla-5.17 zu starten.
Gruss,
S:oren
PS: Ist vielleicht nicht ganz fair, diesen Thread fuer ein komplett anderes Thema zu hijacken...
Du nutzt eine S2-6400 mit 5.16er Kernel ohne meinen Treiber?
https://github.com/s-moch/linux-saa716x
Gruss,
S:oren
Ich habe in dem System eine tt6400 als Ausgabedevice und eine Digital Devices v7 mit Erweiterung zum Empfangen, somit brauche ich beide Treiber.
Mit einem Vanilla 5.17.0 wird die Digital Devices Karte und das Erweiterungsmodul erkannt wie auch mit dem Gentoo 5.17.0, aber damit habe ich keinen Treiber für die Ausgabe.
S:oren Ich benutze https://packages.gentoo.org/pa…/media-tv/v4l-dvb-saa716x
Das ist https://bitbucket.org/powARman/v4l-dvb-saa716x plus ein paar Patche damit es sich mit aktuellen kerneln compilieren lässt.
Ich habe in dem System eine tt6400 als Ausgabedevice und eine Digital Devices v7 mit Erweiterung zum Empfangen, somit brauche ich beide Treiber.
Mit einem Vanilla 5.17.0 wird die Digital Devices Karte und das Erweiterungsmodul erkannt wie auch mit dem Gentoo 5.17.0, aber damit habe ich keinen Treiber für die Ausgabe.
So ein Setup kann ich nicht testen. Ich habe auch keine Idee, wieso sich Aenderungen am I2C-Controller des saa716x-Treibers auf eine Digital Devices v7 auswirken sollten.
Gruss,
S:oren
S:oren Ich benutze https://packages.gentoo.org/pa…/media-tv/v4l-dvb-saa716x
Das ist https://bitbucket.org/powARman/v4l-dvb-saa716x plus ein paar Patche damit es sich mit aktuellen kerneln compilieren lässt.
Wenn bei Gentoo der alte Stand besser funktioniert, oder zumindest nicht schlechter, dann ist ja gut.
Da Sachen wie "import fixes from https://github.com/s-moch/linux-saa716x" hinein zu packen, statt gleich meinen Treiber zu nehmen, ist bestimmt eine gute Idee, um Entwicklungs- und Testressourcen zu buendeln und effektiv zu nutzen. Aber ja, die Lizenz erlaubt das.
Gruss,
S:oren
Ich habe auch keine Idee, wieso sich Aenderungen am I2C-Controller des saa716x-Treibers auf eine Digital Devices v7 auswirken sollten.
Außer vielleicht, dass doch nicht beide Treiber (und dvb-core) aus den selben Sourcen mit identischer config gebaut wurden...
Gruß,
Sören
Ich habe die .config vom saa761x-5.17-test Kernel genommen und in das Quellverzeichnis vom Gentoo bzw. Vanilla Kernel kopiert.
Weitere Treiber bentze ich aktuell nicht. Ich habe bei 5.16 kurz den Digital Devices Treiber installiert damit ich Firmware aktualisieren kann, dann ging aber die S2-6400 nicht weil der DD Treiber einen eigenen dvb-core mitbringt, deshalb bin ich nach dem Firwareupdate wieder zurück zum Kernel Treiber.
Ich benutze den linux- saa761x Kernel seit 4.16 und hatte bis jetzt keinen Konflikt zwischen den Karten, am Anfang hatte ich allerdings eine v6 Modul an einer Octopus da die neueren Module und Karten noch nicht vom Kernel Treiber unterstützt wurden.
Ich habe die .config vom saa761x-5.17-test Kernel genommen und in das Quellverzeichnis vom Gentoo bzw. Vanilla Kernel kopiert.
Wenn das nicht der _selbe_ Kernel ist, dann wird das nicht funktionieren. Jedenfalls nicht zuverlaessig und irgendwie zu debuggen.
Ein paar Beitraege weiter oben steht, dass Gentoo einen (alten) saa716x-Treiber hat. Also sollte man fuer Gentoo wohl den verwenden.
Ich jedenfalls kann keinen Support fuer einen Mix verschiedener Kernel leisten, und auch dieser Thread hat eigentlich nichts damit zu tun. Das war's von mir zu diesem Thema.
Gruss,
S:oren
Heute habe ich den saa761x-5.17-test Kernel noch einmal gebootet um die MSI Option des Digital Devices Modules testweise umzustellen, er läuft jetzt ohne Probleme ohne das ich was geändert habe. Auch nach mehreren Neustarts. Keine Ahnung ob die Karte sich letzte mal wegen was anderes aufgehängt hat oder zu warm war. Die tt6400 und die Digital Devices sind in benachbarten Slots,vielleicht gibt es dadurch Störungen.
Hallo kamel5 ,
auch bei mir habe ich in der letzten Woche keine Probleme mehr feststellen koennen. Ich habe auch ein gutes Gefuehl mit diesem Code. Somit waere es fuer mich absolut OK, das im Titel als erledigt zu betrachten. War ja letztendlich ein bei Dir aufgetretenes Problem, was hoffentlich geloest werden konnte.
Offene Punkte sind fuer mich:
Sollte der Fastmode auch fuer 5.16 mit eingecheckt werden? Ist ja einigermaßen gut getestet.
Sollte man nochmal versuchen, wieder Interrupts zu nutzen, um die usleeps zumindest fuer writes loszuwerden? Hauptproblem hier (neben der Zeit fuer die Implementierung) ist der Test mit Budget-Karten. Da der Treiber jetzt ja schon recht "willig" reagiert, ist der Nutzen vielleicht nicht so groß, dass sich das lohnt.
Was ist mit 5.17? Wann kann das jemand außer mir testen? Wann kann das -test aus dem Branch gestrichen werden?
Gruss,
S:oren
Sollte der Fastmode auch fuer 5.16 mit eingecheckt werden? Ist ja einigermaßen gut getestet.
Ich denke das kannst Du machen. Ich habe es genau so ja laufen und bisher keine Probleme dadurch festgestellt.
Sollte man nochmal versuchen, wieder Interrupts zu nutzen, um die usleeps zumindest fuer writes loszuwerden? Hauptproblem hier (neben der Zeit fuer die Implementierung) ist der Test mit Budget-Karten. Da der Treiber jetzt ja schon recht "willig" reagiert, ist der Nutzen vielleicht nicht so groß, dass sich das lohnt.
Ohne einen geeigneten Tester würde ich das im Moment nicht machen. Ich kann da leider bei Budget-Karten keine Unterstützung geben.
Was ist mit 5.17? Wann kann das jemand außer mir testen? Wann kann das -test aus dem Branch gestrichen werden?
Ich würde das "-test" streichen. Im Moment sehe ich da ja nur den Unterschied bzgl. Fastmode und das läuft ja schon mit 5.16.
Sobald ich hier 5.17 angeboten bekomme, schaue ich mir das gerne nochmal an.
Grüße
kamel5
Hab den Treiber fuer die Kernelversionen 5.15 bis 5.17 auf den gleichen neuen Stand gebracht.
5.15 habe ich noch kurz getestet. Ein Backport der I2C-Anpassungen fuer aeltere Kernelversionen ist sicher moeglich, wenn sich ein Tester findet...
Gruss,
S:oren
Hallo S:oren ,
Sobald ich hier 5.17 angeboten bekomme, schaue ich mir das gerne nochmal an.
Die Tests haben jetzt doch etwas länger gedauert, ich hatte zwischendurch Probleme mit Kernel 5.17.5. Deshalb habe ich erst einmal abgewartet wie es mit den folgenden aussieht. Die neueren funktionieren aber prinzipiell wieder und der neue Treiber macht es deutlich besser als der alte.
Ein Problem habe ich aber doch noch, und wahrscheinlich bin ich auch diesmal wieder der Einzige, der das hat (vielleicht liegt es doch an meiner "exotischen" Hardware).
Dieses Problem gab es bei mir auch schon mit dem alten Treiber, deshalb habe ich es nicht mit dem neuen in Verbindung gebracht:
Wie man sieht, ist das OSD kaputt. Dieses Problem tritt nicht reproduzierbar, aber immer wieder sporadisch auf.
Dieses extrem kaputte OSD ist auch nicht repräsentativ, meistens ist das Ausmaß geringer und es befindet sich überwiegend im unteren Bereich.
Es spielt auch keine Rolle, welcher Skin oder welches Plugin dabei aktiv ist.
Was sich jetzt verändert hat, ist die Häufigkeit des Auftretens. Durch diese Änderung ".i2c_rate = SAA716x_I2C_RATE_400" tritt das Problem deutlich häufiger und umfangreicher auf. Ich weiß nicht, ob es da einen logischen Zusammenhang geben kann.
Jedenfalls habe ich diese Änderung aktuell rückgängig gemacht, und das Problem tritt wieder sichtlich weniger auf.
Und dann habe ich noch eine bei mir in Vergessenheit geratene Sache, die auf Grund der Bildschirmfotos wieder aufgetaucht ist:
Die VDR Bildschirm-Grab Funktion (svdrpsend grab):
Das hat bei mir noch nie mit der TT6400 funktioniert. Vor Jahren war es mal so, das das Grab zwar durchgeführt wurde, es dann aber nur eine komplett grüne Grafik gab. Mittlerweile ist es aber so, und das hat nichts primär mit dem neuen Treiber zu tun, hängt dann der VDR (Videobild läuft weiter, auch im Tranfermode, es werden aber keine Befehle mehr angenommen) und auch ein Restart des Rechners funktioniert nicht mehr. Es hilft nur noch ein Aus/Einschalten.
Da es bisher darüber noch keine Meldungen gab, ich also durchaus wieder der Einzige sein könnte, bei dem es nicht funktioniert, wollte ich es aber trotzdem mal erwähnen um zu hören, ob es vielleicht bei Anderen geht.
Grüße
kamel5
Was sich jetzt verändert hat, ist die Häufigkeit des Auftretens. Durch diese Änderung ".i2c_rate = SAA716x_I2C_RATE_400" tritt das Problem deutlich häufiger und umfangreicher auf. Ich weiß nicht, ob es da einen logischen Zusammenhang geben kann.
Das OSD hat nichts mit dem I2C zu tun. Sieht eher nach einem Hardwareproblem aus. Eventuell koennte helfen, die S2-6400 nicht komplett ganz in den PCIe-Slot zu stecken, sondern um einen halben Millimeter weniger. Wenn das einen Unterschied macht, dann vorsichtig den Loetstopplack von den PCIe-Pins abkratzen, vorsichtig einen halben Millimeter an der Kante zu den freiliegenden Pins, nur den Lack, nicht die Vergoldung.
Die VDR Bildschirm-Grab Funktion (svdrpsend grab):
Das hat bei mir noch nie mit der TT6400 funktioniert.
Da gibt es einen Modulparameter, um das Grab (single-shot) einzuschalten. Hatte mal vor langer Zeit funktioniert. Hab's seitdem nicht wieder ausprobiert.
Wenn das OSD kaputt ist, kann das selbe Hardwaereproblem natuerlich auch das Grab beeinflussen. Hab sonst keine Idee im Moment dazu.
Gruss,
S:oren
Das OSD hat nichts mit dem I2C zu tun. Sieht eher nach einem Hardwareproblem aus. Eventuell koennte helfen, die S2-6400 nicht komplett ganz in den PCIe-Slot zu stecken, sondern um einen halben Millimeter weniger. Wenn das einen Unterschied macht, dann vorsichtig den Loetstopplack von den PCIe-Pins abkratzen, vorsichtig einen halben Millimeter an der Kante zu den freiliegenden Pins, nur den Lack, nicht die Vergoldung.
Ok, das werde ich mir mal längerfristig ansehen, ich kann auch noch eine 2. TT6400 testen, ob die sich anders verhält.
Bezüglich ".i2c_rate = SAA716x_I2C_RATE_400", lassen sich da eigentlich auch Zwischenfrequenzen einstellen, oder sind die beiden Werte fest vorgegeben?
Da gibt es einen Modulparameter, um das Grab (single-shot) einzuschalten. Hatte mal vor langer Zeit funktioniert. Hab's seitdem nicht wieder ausprobiert.
Wenn das OSD kaputt ist, kann das selbe Hardwaereproblem natuerlich auch das Grab beeinflussen. Hab sonst keine Idee im Moment dazu.
Ja, den Modulparameter "options saa716x_ff video_capture=1" habe ich aktiv.
Das ist für mich zwar keine wichtige Funktion, bevor ich da aber weiter suche, würde es mich schon interessieren, ob es grundsätzlich funktionieren müsste. Vielleicht könntest Du das bei Gelegenheit mal ausprobieren.
Grüße
kamel5
Bezüglich ".i2c_rate = SAA716x_I2C_RATE_400", lassen sich da eigentlich auch Zwischenfrequenzen einstellen, oder sind die beiden Werte fest vorgegeben?
Das sind die Werte aus dem I2C-Standard (Standard-Mode, Fast-Mode). Der SAA7160 selbst koennte vermutlich auch Fast-Mode-Plus (1 MBit/s) und alles dazwischen (mehr oder weniger exakt). Normalerweise stellt man immer den schnellsten Modus ein, den alle Busteilnehmer unterstuetzen.
Die I2C-Frequenz beeinflusst schon irgendwie die zeitlichen Ablaeufe auf dem PCIe-Bus mit VDR, aber wenn es ein OSD-Problem auch mit langsamstem I2C gibt, wird eine andere Frequenz da nur zufaellig etwas verbessern oder verschlechtern.
Vielleicht könntest Du das bei Gelegenheit mal ausprobieren.
Muss ich erstmal wieder herausfinden, wie das genau geht...
Gruß,
S:oren
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
