Optimierung des Datendurchsatzes (Wiedergabe / Transfermode / OSD) auf TT S2-6400

    Bei der Nutzung meiner TT S2-6400 an meinem ARM-System ist mir aufgefallen, dass bei Wiedergabe oder Transfermode relativ viel CPU-Zeit fuer die Ausgabe des TS-Datenstroms verbraucht wird. Ich habe hier einen Treiberpatch und ein neues FPGA-Firmwarefile, damit kann ich auf diesem System mehr als die vierfache Durchsatzrate erzielen, die CPU-Last reduziert sich entsprechend. Auch skinnopacity (als komplexeres Skin) ist damit gut benutzbar, waehrend es ohne den Patch schon recht traege ist.


    Um herauszufinden, wie gut der Patch auf anderen CPU-Architekturen funktioniert, moechte ich in diesem Thread interessierte VDR-Nutzer mit S2-6400 aufrufen, den Treiberpatch zu testen. Obwohl ich den Patch seit einigen Wochen erfolgreich in meinem Produktivsystem nutze, richtet sich dieser Thread ausdruecklich nicht an den Nur-Anwender, Kenntnisse im Patchen und Bauen des Treibers und installieren der Firmware sollten vorhanden sein. Auch gibts es keine Funktionsgarantie, also bitte keine Beschwerden. ;)


    Wer immer noch nicht abgeschreckt wurde, kann das angehaengte Firmwarefile nach dem Entpacken (gunzip) als dvb-ttpremium-fpga-01.fw ins Firmwareverzeichnis legen oder verlinken und mit dem angehaengten diff-File den Treiber patchen. Dann gibt es 2 neue Modulparameter, phi_mode mit Wertebereich 0 bis 5 und phi_clk mit Wertebereich 0 bis 2. Mit phi_mode werden unterschiedliche Zugriffsmethoden auf die PCIe-Brigde eingestellt. Bei mir funktionieren alle Modi, sind aber unterschiedlich schnell. Auf meinem ARM-System ist z.B. Mode 4 am schnellsten, auf x86 Mode 0. Mit phi_clk werden verschieden schnelle Takte in der Bridge benutzt, funktioniert bei mir auch mit allen Werten, mit hoeheren Werten immer etwas schneller.


    Beim Testen empfehle ich folgendes Vorgehen:
    In einem ersten Schritt bitte den Parameter phi_clk auf 0 lassen und die verschiedenen Moeglichkeiten von phi_mode (0 bis 5) ausprobieren. Zunaechst muss das OSD fehlerfrei funktionieren, danach die Wiedergabe einer (HD-)Aufnahme mit moeglichst hoher Bitrate starten und die CPU-Last des kworker/u-Threads z.B. mit 'top-H' checken und merken (ggf. die Summe der CPU-Last, wenn es mehrere kworker/u-Threads gibt). Im Idealfall funktionieren alle Modi fehlerfrei, die CPU-Last ist bei manchen Modi gleich, bei anderen Modi unterschiedlich (dabei jedoch immer ungefaehr proportional zur Bitrate des TS-Datenstroms, deshalb den Test moeglichst immer an der selben Stelle der Aufnahme durchfuehren).
    Fuer den schnellsten PHI-Mode kann anschliessend noch der phi_clk-Parameter geaendert werden, sollte dann hoffentlich noch etwas schneller werden.
    Sollten mit irgendwelchen Settings Fehler auftreten, dann bitte vor dem Test mit anderen Parametern den Rechner komplett 'runterfahren und nicht nur rebooten.


    Die neue FPGA-Firmware sollte auch mit dem Originaltreiber ohne Patch funktionieren, dieser Fall kann gerne als Referenz noch mitgemessen werden (Patch mit alter Firmware geht umgekeht nicht!).


    Fuer mich interessant ist nun, welcher Mode am schnellsten ist, und welcher ggf. nicht funktioniert. Dazu bitte immer die CPU-Architektur, Anzahl (logische) Kerne und genutzte Kernelversion mit angeben.
    Bitte in diesem Thread nur diese Testergebnisse oder mit dem Test zusammenhaengende Fragen posten. Bitte keine Statements in der Art: Ich habe gar keine S2-6400, finde die Karte aber total toll. ;)


    Vielen Dank,
    S:oren



    Edit: aktuelle Versionen von Treiberpatch und FPGA-Firmware befinden sich hier

    Hallo S:oren,


    schön, das Du für die TT6400 noch was machst.


    Ich habe die neue Firmware mit dem Treiberpatch bei mir mal getestet und folgendes festgestellt:


    Alte Firmware/Treiber 13%
    phi_mode=0 phi_clk=0 -> 10%; Menü fehlerhaft
    phi_mode=1 phi_clk=0 -> 11%    ; Menü fehlerhaft
    phi_mode=2 phi_clk=0 -> 12%; Menü fehlerhaft
    phi_mode=3 phi_clk=0 -> 5,8..6,5%; phi_clk=1 -> 3,9..4,5%; phi_clk=2 -> 3,2..3,9%
    phi_mode=4 phi_clk=0 -> 6,0..6,5%; phi_clk=1 -> 3,9..4,5%; phi_clk=2 -> 3,3..3,9%
    phi_mode=5 phi_clk=0 -> 5,8..6,5%; phi_clk=1 -> 3,9..4,5%; phi_clk=2 -> 3,2..3,9%

    Die Prozente sind die Summe CPU-Last der kworker/u-Threads. Da diese doch erheblich schwanken, sind die Werte nur als Tendenz zu sehen mit Abweichungen nach oben und unten. Es gibt hier einen kworker mit hoher Last und 0-x mit kleiner Last.


    Bei den phi_mode 0..2 wird das Menü im Live-Mode erst korrekt dargestellt bis die Wiedergabe einer Aufzeichnung gestartet wurde. Während der Wiedergabe und nach Ende wird das Menü verpixelt bis unleserlich oder gar nicht mehr angezeigt, außerdem wird es dann sehr langsam. Eine Bedienung, auch blind, ist dann fast nicht mehr möglich.

    Vom Gefühl her sind die phi_mod 3 und 5 bei mir die "Schnellsten", phi_mod 4 ist tendenziell etwas "langsamer".


    Ich werde die phi_mode 3 bis 5 die nächsten Tage weiter beobachten, ob sich hier im laufenden Betrieb noch Unzulänglichkeiten zeigen.



    Meine Hard/Software:


    CPU Phenom II 6-Kern
    Kernel 3.10.3 x86_64


    Signatur ist aktuell


    Gruß


    Karl


    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.8 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

    kamel5: Vielen Dank fuer den Test!


    Ist ja schon mal eine gute Nachricht, dass auch auf einem 6-Kern x86_64-System eine Durchsatzsteigerung von etwa Faktor 4 erreichbar ist.
    Die OSD-Fehler sollten allerdings nicht auftreten. Um dem Problem auf die Spur zu kommen, kannst Du bitte noch testen, ob auch mit dem originalen Treiber ohne Patch aber mit der neuen FPGA-Firmware die OSD-Fehler da sind?


    Ansonsten ist ja besonders schoen, dass die funktionierenden Modi auch die schnellsten sind.


    Zum Test, ob auch das OSD schneller geworden ist, kann man zum Beispiel das femon-Plugin starten und mit 'top -H' die CPU-Zeit des VDR-Hauptthreads beobachten. Der Unterschied ist hier aber nicht so gross, da in diesem Thread ja neben dem OSD-Datentransfer noch viele andere Sachen gemacht werden.


    Gruss,
    S:oren

    Zitat von S:oren

    Die OSD-Fehler sollten allerdings nicht auftreten. Um dem Problem auf die Spur zu kommen, kannst Du bitte noch testen, ob auch mit dem originalen Treiber ohne Patch aber mit der neuen FPGA-Firmware die OSD-Fehler da sind?

    Ich hab das gerade mal probiert, ja die Menü-Fehler treten auch in dieser Kombination schon auf.


    Das mit dem femon-Plugin werde ich mir auch mal ansehen.


    Was mir allerdings bei den aktuellen Tests aufgefallen ist: bei phi_clk=2 gibt es bei manchen Sendern Bild und Tonstörungen (bei den phi_mode 3..5, die anderen habe ich jetzt nicht weiter verfolgt), die mit phi_clk 0 und 1, sowie mit der ursprünglichen Firmware/Treiberkombination nicht auftreten, ich werde das mal weiter verfolgen.


    In meiner Konfiguration sind im Moment also die phi_mode 3, 4 und 5 jeweils mit phi_clk 0 und 1 ohne Probleme benutzbar.


    Aufgefallen ist mir auch noch, das die neue Firmware/Treiberkombination recht sensibel auf Entladen und Neuladen der Treiber reagiert.
    Das klappt manchmal nicht, obwohl vorher kein sichtbarer Fehler aufgetreten ist, die Wahrscheinlichkeit steigt dabei mit phi_clk.
    Das Log sieht dann z.B. so aus:


    Code
    Aug  3 19:58:52 home-05 kernel: [ 1169.473407] SAA716x FF FPGA version 0.00
Aug  3 19:58:52 home-05 kernel: [ 1169.524461] SAA716x FF loader version 1.03
Aug  3 19:58:53 home-05 kernel: [ 1170.534855] SAA716x FF: probe of 0000:05:00.0 failed with error -1


    Als FPGA version werden aber auch andere Zahlenkombinationen angegeben.


    Gruß
    Karl


    PS: nur zum Verständnis: die Prozentwerte in meinem vorhergehenden Post beziehen sich auf einen Kern, falls die Werte für diese CPU etwas hoch erscheinen sollten.

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.8 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

    Zitat von kamel5

    Aufgefallen ist mir auch noch, das die neue Firmware/Treiberkombination recht sensibel auf Entladen und Neuladen der Treiber reagiert.

    Hm, da stimmt also mit dem Reset noch irgendwas nicht.


    Zitat von kamel5

    die Prozentwerte in meinem vorhergehenden Post beziehen sich auf einen Kern, falls die Werte für diese CPU etwas hoch erscheinen sollten

    Ich haette fuer einen Kern ziemlich genau die doppelten Werte erwartet (bei einem 13 MBit/s Datenstrom), hat das vielleicht mit den 2-Kern-Bulldozer-Modulen zu tun? Haengt ansonsten aber sehr von der Datenrate ab, deshalb ist das Lastverhaeltnis in den verschiedenen Modi interessanter als der absolute Wert.


    Gruss,
    S:oren

    Zitat von S:oren

    Hm, da stimmt also mit dem Reset noch irgendwas nicht.


    Apropos Reset: Scheinbar gibt es beim Initialisieren der Karte auch noch ein Problem.


    Folgendes Verhalten habe ich jetzt seit längerem mit der Karte nach einem Kaltstart:
    Also Rechner wird eingeschaltet -> Treiber werden geladen -> VDR startet -> Bild wird nur dargestellt, wenn es ein SD-Kanal ist, HD-Kanäle werden zu 90% nicht angezeigt. Nach einem Kanalwechsel, egal ob zu HD oder SD, wird kein Bild mehr angezeigt.


    Was immer geht, ist das Menü. Je öfter ich jetzt einen Kanal wechsle umso träger wird das Ganze aber. Helfen tut hier nur ein Neuladen der Treiber, und zwar ein bis mehrmals.
    Läuft die Karte dann erst einmal richtig, gibt es auch langfristig keine weiteren Probleme. Ein Neustart des Rechners ist also nicht nötig. Was noch auffällig ist, die Probleme treten nur im Wiedergabebereich der Karte auf, denn Aufnahmen werden immer, auch nach dem ersten Laden der Treiber, korrekt durchgeführt.


    Geholfen habe ich mir bisher damit, das ich vor dem Start vom VDR den Treiber zweimal laden lasse und dann ggfs. beim Livebetrieb noch händisch ein bis zweimal den VDR mit Treiber-Neuladen neu starte.


    Das Problem gibt es auch noch nicht immer. Leider kann ich nicht mehr sagen, wann genau es zuerst auftrat, da ich damals ein Betriebssystemupgrade gemacht und immer darauf geschoben habe. Allerdings habe ich in dem Zeitraum auch neue Treiber und Firmware installiert.


    Bei einem Warmstart des Rechners konnte ich das Problem bisher nicht feststellen.


    Zitat von S:oren

    Ich haette fuer einen Kern ziemlich genau die doppelten Werte erwartet


    Ja, OK. Ich kann hier nicht wirklich sagen, wie hoch die Datenrate bei dieser Aufzeichnung war. Die Werte schwanken allerdings sehr stark , es traten dabei Schwankungen von weniger als der Hälfte bis mehr als das Doppelte dieser genannten Werte im Laufe der Wiedergabe auf. Die Tendenz ist aber wirklich eindeutig.



    Gruss


    Karl

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.8 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

    Zitat von kamel5

    Scheinbar gibt es beim Initialisieren der Karte auch noch ein Problem. [...] Helfen tut hier nur ein Neuladen der Treiber, und zwar ein bis mehrmals. [...]

    Das hoert sich ja alles richtig gruselig an. Es ist natuerlich schwierig, neue Treiberaenderungen zu testen, wenn schon der bisherige Treiber so instabil laeuft.


    Zitat

    Das Problem gibt es auch noch nicht immer. Leider kann ich nicht mehr sagen, wann genau es zuerst auftrat, da ich damals ein Betriebssystemupgrade gemacht und immer darauf geschoben habe. Allerdings habe ich in dem Zeitraum auch neue Treiber und Firmware installiert.

    Ohne irgendwelche Hinweise, was genau zu dem Problem gefuehrt hat, kann ich nicht wirklich helfen.


    Zitat

    Ich kan hier nicht wirklich sagen, wie hoch die Datenrate bei dieser Aufzeichnung war. Die Werte schwanken allerdings sehr stark , es traten dabei Schwankungen von weniger als der Hälfte bis mehr als das Doppelte dieser genannten Werte im Laufe der Wiedergabe auf. Die Tendenz ist aber wirklich eindeutig.

    Wie gesagt, die absoluten Werte sind nicht so wichtig, nur die relative Aenderung durch den Patch. Da ergibt sich ja die selbe Verbesserung, die ich auch bei mir gesehen habe.


    Patch und Firmware sind ja einige Male heruntergeladen worden, hat sonst noch jemand Verbesserungen oder Probleme beobachtet?


    Gruss,
    S:oren

    Ich habe den Patch mal eingebaut und werde morgen berichten können.


    DANKE das du weiter an der TT S2-6400 fest hältst :)

    ------
    Hardware: ASUS E35M1-I Deluxe, 4GB RAM, ATI on Board (fuer Kodi), TT S2-6400 FF, Samsung 500GB 2,5"
    VDR: MLD5

    ich stell mich gerade zu glatt an :rolleyes:


    ist doch richtig das ich die modprobe configuration so anpasse oder?


    Code
    options saa716x_ff phi_mode=3 phi_clk=0


    irgendwas will bei mir noch nicht so wie ich will


    BTW: hatte ich ohne Angabe der Module Optionen ,mit der neuen Firmware, ein verzogenes OSD Menü

    ------
    Hardware: ASUS E35M1-I Deluxe, 4GB RAM, ATI on Board (fuer Kodi), TT S2-6400 FF, Samsung 500GB 2,5"
    VDR: MLD5


    verzögert sich..


    warum will der die parameter nicht ...der patch "sollte" drin sein

    ------
    Hardware: ASUS E35M1-I Deluxe, 4GB RAM, ATI on Board (fuer Kodi), TT S2-6400 FF, Samsung 500GB 2,5"
    VDR: MLD5

    Vielen Dank erstmal fuer die bisherigen Tests.


    Zitat von kamel5

    Während der Wiedergabe und nach Ende wird das Menü verpixelt bis unleserlich oder gar nicht mehr angezeigt, außerdem wird es dann sehr langsam.

    Zitat von kamel5

    Aufgefallen ist mir auch noch, das die neue Firmware/Treiberkombination recht sensibel auf Entladen und Neuladen der Treiber reagiert.
    Das klappt manchmal nicht, obwohl vorher kein sichtbarer Fehler aufgetreten ist, die Wahrscheinlichkeit steigt dabei mit phi_clk.

    Zitat von PaulPanther

    BTW: hatte ich ohne Angabe der Module Optionen ,mit der neuen Firmware, ein verzogenes OSD Menü


    Hier habe ich neue Versionen von Treiberpatch und FPGA-Firmware, die diese Probleme hoffentlich beheben. Da diese Fehler bei mir nicht aufgetreten waren, weiss ich natuerlich auch nicht, ob es damit wirklich besser wird...


    Gruss,
    S:oren

    Zitat von kamel5

    Aufgefallen ist mir auch noch, das die neue Firmware/Treiberkombination recht sensibel auf Entladen und Neuladen der Treiber reagiert.
    Das klappt manchmal nicht, obwohl vorher kein sichtbarer Fehler aufgetreten ist, die Wahrscheinlichkeit steigt dabei mit phi_clk.

    Nochmal zur Klarstellung: der neue Treiberpatch sollte die Abhaengigkeit der Reset-Probleme von phi_clk beseitigen. Am generellen Verhalten habe ich nichts geaendert (ich nutze den Treiber ueblicherweise direkt im Kernel, nicht als Modul). Im Moment ist es also besser, neu zu booten als die saa716x-Module zu entladen und (ggf. mit anderen Parametern) ohne reboot neu zu laden.


    Noch ein Trick: den phi_mode kann man online aendern, z.B.

    Code
    echo 4 > /sys/module/saa716x_core/parameters/phi_mode

    Mit phi_clk klappt das nicht, dieser Parameter wird nur beim Laden des Treibers ausgewertet!


    Gruss,
    S:oren

    Zitat von S:oren

    Hier habe ich neue Versionen von Treiberpatch und FPGA-Firmware, die diese Probleme hoffentlich beheben.

    Ich will mal kurz einen ersten Zwischenbericht geben.


    Zitat von S:oren

    Zitat von »kamel5«
    Bei den phi_mode 0..2 wird das Menü im Live-Mode erst korrekt dargestellt bis die Wiedergabe einer Aufzeichnung gestartet wurde. Während der Wiedergabe und nach Ende wird das Menü verpixelt bis unleserlich oder gar nicht mehr angezeigt, außerdem wird es dann sehr langsam.

    Die phi_mode 0..2 funktionieren jetzt genau so wie die Restlichen. Das Menü wird jetzt prinzipiell korrekt dargestellt, auch nach einer Aufzeichnungswiedergabe.
    Die phi_mode 0..2 liegen in ihrem Lastverhalten bei meiner Hardware deutlich schlechter als die phi_mode 3..5, Werte liefere ich dann noch, wenn ich mit den Tests durch bin.


    Zitat von S:oren

    Zitat von »kamel5«
    Aufgefallen ist mir auch noch, das die neue Firmware/Treiberkombination recht sensibel auf Entladen und Neuladen der Treiber reagiert.
    Das klappt manchmal nicht, obwohl vorher kein sichtbarer Fehler aufgetreten ist, die Wahrscheinlichkeit steigt dabei mit phi_clk.

    Zitat von S:oren

    Nochmal zur Klarstellung: der neue Treiberpatch sollte die Abhaengigkeit der Reset-Probleme von phi_clk beseitigen. Am generellen Verhalten habe ich nichts geaendert (ich nutze den Treiber ueblicherweise direkt im Kernel, nicht als Modul). Im Moment ist es also besser, neu zu booten als die saa716x-Module zu entladen und (ggf. mit anderen Parametern) ohne reboot neu zu laden.


    Das Resetproblem konnte ich bisher bei allen phi_mode und den phi_clk 0 und 1 nicht feststellen. Bei einem Kurztest eines phi_clk 2 hatte ich sowohl einmalig bisher ein Menüproblem, sowie ein Resetproblem. Das werde ich weiter untersuchen.


    Zu meinem Kaltstartproblem muss ich positiv feststellen, das mit Deiner neuen Firmware/Treiberkombination, selbst mit RC1/test1, nach längerem Testen der Effekt sehr viel weniger auftritt als mit der vorhergehenden stabilen Version. Ich konnte sogar das mehrmalige Laden des Treibers absolut minimieren.


    Das Einkompilieren des Treibers ist für mich auch nicht wirklich eine Option, da bei Fedora bekanntlich doch recht häufig Kernel-Updates kommen. Es ist für mich einfacher, die Treiber zum Kernel dazu zu kompilieren. Das hat bisher ohne Probleme geklappt. Ein Neuladen der Treiber war bisher auch nie ein Problem.
    Sollte es zu Unregelmäßigkeiten, z.B. wie jetzt bei den Tests, kommen, habe ich den Rechner zum Verifizieren immer noch mal neu gestartet.


    Zitat von S:oren

    Noch ein Trick: den phi_mode kann man online aendern, z.B.

    Quellcode


    1 echo 4 > /sys/module/saa716x_core/parameters/phi_mode

    Gut zu wissen, das erspart dann einen Arbeitsschritt.


    Im Moment stellen sich also für meine Hardware alle phi_mode, jeweils mit den phi_clk 0 und 1 als funktionsfähig dar.
    phi_clk 2 ist noch nicht stabil.


    Gruss


    Karl

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.8 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

    Hallo zusammen,


    ich wollte gerade auch mal den Patch testen. Leider scheitere ich daran wo genau ich den Patch anwenden muss. Ich nutzte den aktuellen media_build_experimental von UFO. Dort finde ich die Sourcen unter


    ./linux/drivers/media/common/saa716x


    und auch unter


    /experimental/v4l-dvb-saa716x/linux....


    unter letzterem Pfad kann ich den Patch ohne Fehler anwenden, aber der Treiber der dann gebaut wird enthält nicht die neuen Parameter. Unter dem ersten Pfad scheint der Patch nicht zu passen


    Hat jemand einen Tipp für mich?


    Vielen Dank schon mal,
    Christian

    VDR1: Debian 6.0.10, VDR 2.0.6, Kernel 3.2.36+mb_experimental, Zotac E350-ITX + TT6400 + DD DuoFlex-CTv2 Octopus mini PCIe + Noxon DAB Stick
    VDR2: Debian 6.0.10, VDR 2.0.6, Kernel 3.7.1+mb_experimental,, Zotac IONITX-S-E + TT6400 + DD DuoFlex-CTv2 mini PCIe

    Hallo,


    danke für den Tipp, so konnte ich den Treiber bauen. Die Verminderung der CPU Last bei der Wiedergabe ist vorhanden aber leider habe ich dann Fehler im Bild:


    phi_mode 0 1 2 3 4 5
    cpu 13% 13% 13% 8% 8% 8%


    Ab phi_mode 3 habe ich Bildstörungen. phi_clk scheint keinen Einfluss zu haben. Die Umschaltung habe ich bei laufender Wiedergabe mittels echo x > /sys... ausgeführt.


    Wenn ich den Modulparameter in der modules.conf setzte kann der Treiber ab phi_mode 3 nicht sauber geladen werden. Mein Testsystem ist das System 2 aus meiner Signatur (ATOM D525 + NM10)


    Gruß,
    Christian

    VDR1: Debian 6.0.10, VDR 2.0.6, Kernel 3.2.36+mb_experimental, Zotac E350-ITX + TT6400 + DD DuoFlex-CTv2 Octopus mini PCIe + Noxon DAB Stick
    VDR2: Debian 6.0.10, VDR 2.0.6, Kernel 3.7.1+mb_experimental,, Zotac IONITX-S-E + TT6400 + DD DuoFlex-CTv2 mini PCIe

    Einmal editiert, zuletzt von CyberChris ()

    Zitat von CyberChris

    Ab phi_mode 3 habe ich Bildstörungen. phi_clk scheint keinen Einfluss zu haben. Die Umschaltung habe ich bei laufender Wiedergabe mittels echo x > /sys... ausgeführt.

    Hm, schade. Was heisst "Bildstoerungen"? OSD kaputt, Video kaputt? Bloecke oder gar kein Bild? Mit und ohne OSD die gleichen Fehler?
    phi_clk laesst sich _nicht_ mit der echo-Methode umschalten (siehe oben). Da sind hoehere Werte aber sowieso nur sinnvoll, wenn der entsprechende phi_mode mit phi_clk 0 funktioniert.


    Zitat von CyberChris

    Wenn ich den Modulparameter in der modules.conf setzte kann der Treiber ab phi_mode 3 nicht sauber geladen werden. Mein Testsystem ist das System 2 aus meiner Signatur (ATOM D525 + NM10)

    Was passiert, wenn der Treiber nicht richtig geladen wird? Irgendwas im Log?
    Das ist ein Dual-Core-Atom ohne Hyperthreading? Laeuft der als x86_32 oder x64?


    Gruss,
    S:oren

    Zitat von S:oren


    Hm, schade. Was heisst "Bildstoerungen"? OSD kaputt, Video kaputt? Bloecke oder gar kein Bild? Mit und ohne OSD die gleichen Fehler?


    Das Video enthält mal mehr mal weniger umherwandernde Blockartefakte mit Falschfarben an unterschiedlichen Stellen. Manchmal auch Tonstörungen. Die Störungen sind um so höher je höher die Bitrate des Videos ist. (Also bei HD schlimmer als bei SD) Das OSD selbst ist immer okay.


    Zitat von S:oren

    Was passiert, wenn der Treiber nicht richtig geladen wird? Irgendwas im Log?
    Das ist ein Dual-Core-Atom ohne Hyperthreading? Laeuft der als x86_32 oder x64?



    Der Atom hat zwei Cores (1.8GHz) die Hyperthreading können und es ist ein x86_32 Kernel. Ach ja, der Kernel ist extra mit der Prozessoreinstellung für ATOM Prozessoren gebaut.


    Gruß,
    Christian

    VDR1: Debian 6.0.10, VDR 2.0.6, Kernel 3.2.36+mb_experimental, Zotac E350-ITX + TT6400 + DD DuoFlex-CTv2 Octopus mini PCIe + Noxon DAB Stick
    VDR2: Debian 6.0.10, VDR 2.0.6, Kernel 3.7.1+mb_experimental,, Zotac IONITX-S-E + TT6400 + DD DuoFlex-CTv2 mini PCIe

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden