I2C Timeouts mit ddbridge

  • 4.12.14-lp150.12.58-default

    Wie JRIE schrieb - vermutlich ab 4.14 drin ... den gibt es inzwischen auch schon eine Weile

    https://www.heise.de/ct/artike…4-14-3831941.html?seite=7  

    Wenn ich mich recht erinnere war auch Umschalten etwas flotter als mit dem DDBridge Kernelmodul.
    Ich bin damals von YaVDR auf MLD gewechselt weil der mitgelieferte Kernel da neuer war und ich bei YaVDR Probleme hatte den aktuelleren Kernel ins System zu bringen (LIRC Änderungen)


    Cine S2 V6.5 + DuoFlex V4 Apollo-Lake Celeron (Asrock J3355M), ATRIC Einschalter, MLD 5.4 testing

  • Ich habe noch vor, folgende Versuche zu machen:


    - Anschluß über ein PCIe Extension Board

    - Anderes Motherboard ASRock J4105M

    - Gleicher Test mit TT S2-6400 (ist ja auch eine PCIe-Karte)


    Zu den ersten beiden warte ich noch auf die Lieferungen.

    Zu Letzterem hat mir S:oren netterweise folgende Anleitung geschickt, wie man den Treiber für die S2-6400 in die Kernel-Source bekommt:

    Code
    1. * Distro-Kernel-Sourcen installieren, evt. auch nochmal kopieren, wenn man das Original nicht anfassen will
    2. * passenden Treiber-Patch aus meinem Repo generieren und auf die (kopierten) Sourcen anwenden
    3. * Distro-Kernel-config hineinkopieren
    4. * 'make localyesconfig', 'make menuconfig' und den Treiber als Modul aktivieren
    5. * 'make -j6 modules'
    6. * die fertigen .ko-Dateien liegen unter drivers/media/common/saa716x oder .../pci/saa716x, je nach Version

    Das Repository ist wohl https://github.com/s-moch/linux-saa716x/tree/saa716x-4.12 (für meinen Kernel 4.12), aber wie man einen "Treiber-Patch" generiert, weiß ich leider nicht. Vielleicht kann mir da ja einer der GIT-Spezialisten hier weiterhelfen...

  • Ich hatte mal ein ASrock j4205-itx damit war die V7A auch nicht stabil zum laufen zu bringen. Hab mir dann die Octopus MiniPCIe Bridge mit Duoflex V4a geholt und mit einem M.2 auf MiniPCIe Adapter an dem M.2 Slot, der eigentlich für Wlan Module da ist, betrieben. Das lief ohne Probleme

  • So, erstmal großes Danke an S:oren für die Hilfe, damit konnte ich jetzt den Treiber für die TT S2-6400 in den Kernel bekommen (hab gleich Kernel 4.19 genommen).


    Test:

    * Phase 1:

    - TT S2-6400 als Empfangsdevice

    - Wiedergabe über vaapidevice

    - rsync des Video-Verzeichnisses über das Netzwerk auf eine remote SSD

    - 6 parallele HD-Aufnahmen (4 auf dem ersten, 2 auf dem zweiten Device)

    - load ca. 4

    - CPU Usage ca. 50%

    - nach ca. 40 Minuten die Aufnahmen auf dem zweiten Device beendet, um EPG-Scan zu erlauben

    - nach weiteren 5 Minuten die restlichen Aufnahmen abgebrochen

    *Phase 2:

    - nach insgesamt ca. einer Stunde rsync abgebrochen, Daten auf der remote SSD aus Platzgründen gelöscht und rsync neu gestartet

    *Phase 3:

    - nach weiteren ca. 45 Minuten Test ohne Fehler abgebrochen

    - TT S2-6400 gegen Cine S2 V7A getauscht, Treiber 0.9.37 (Version 0.9.36 ließ sich nicht mit Kernel 4.19 übersetzen)

    - System neu gestartet, VDR und rsync gestartet

    - schon nach kurzer Zeit (1-2 Minuten) traten CorrErr+ an beiden Enden auf, die auch nach Löschen immer wieder kamen

    - kurz danach I2C Fehler und System nicht mehr brauchbar


    Ergebnis:

    - nach dem Löschen eines anfänglichen CorrErr+ auf der Gegenstation (00:13.1), das wohl vom Booten bzw. Treiber-Laden stammte, entstanden während der gesamten Phase 1 keine CorrErr+, weder bei 00:13.1 noch bei 02:00.0

    - kurz nach dem Beginn von Phase 2 konnten einmalig CorrErr+ an beiden Enden beobachtet werden, nach Löschen traten sie nicht erneut auf

    - während des gesamten Tests mit TT S2-6400 keine I2C-Timeouts

    - mit Cine S2 V7A schon nach kurzer Zeit I2C Fehler


    Schlußfolgerung:

    Während eine TT S2-6400 selbst bei hoher Last und über lange Zeit stabil läuft, verursacht eine Cine S2 V7A auf exakt dem selben System bereits nach wenigen Minuten Fehler und bringt das System in einen Zustand, aus dem nur noch ein Reboot hilft.


    Damit ist es wohl zumindest sehr wahrscheinlich, dass etwas auf der Seite der Cine S2 V7A im Argen liegt.

    Ich schicke den Link auf dieses Posting mal an DD...

  • Hier nun das Ergebnis des Versuchs mit einem PCIe Extension Board.

    'lspci' sieht damit so aus:

    Die S2 V7A ist an 04:00.0 und die Gegenstation ist 03:01.0.


    Bei 8 parallelen HD Aufnahmen (je 4 auf jedem der beiden Devices) und laufendem rsync kommt es immer mal wieder (etwa alle halbe Minute) zu CorrErr+ an 03:01.0, aber nie an 04:00.0.


    Nach etwa 15 Minuten habe ich die Aufnahmen abgebrochen, da die Zugriffe auf das Video-Verzeichnis (welches der rsync ja kopierte) wohl "bremsend" wirken. Auch damit CorrErr+ alle halbe Minute an 03:01.0, aber nie an 04:00.0.

    <edit>Die CorrErr+ an 03:01.0 treten auch ohne Aufnahmen und rsync, mit nur Live-Wiedergabe, auf, aber anscheinend in größerem zeitlichen Abstand (Minuten).</edit>


    Der Test lief ansonsten störungsfrei und wurde nach ca. 50 Minuten beendet.


    Als nächstes folgt noch der Test mit einem ASRock J4105M Motherboard.

    Mach mit beim VDR User Counter!

    The post was edited 1 time, last by kls: Die CorrErr+ an 03:01.0 treten auch ohne Aufnahmen und rsync, mit nur Live-Wiedergabe​, auf, aber anscheinend in größerem zeitlichen Abstand (Minuten). ().

  • Als nächstes folgt noch der Test mit einem ASRock J4105M Motherboard.

    testest Du noch, oder geniest Du schon ;)


    'lspci' sieht damit so aus:

    hattest Du auch mal, bsw mit -vvv an den Beteiligten verglichen, ob sich mit und ohne ext. Bord was ändert?

    Eine Vermutung wäre , das das ext Board dolmetscht und sich so Teiln. A und B deutlich verstehen können. Es könnte aber auch sein, das das ext. Bord quasi als PCI Bremse wirkt (dauerhaft niedriger Transfer Level) und dadurch der "Gesprächsfaden" nicht mehr abreist.

  • Das die Cine überhaupt mit dem Mainboard zusammen läuft, ist schon mal ein Ergebnis.

    Für mich bedeutet das, dass das Mainboard generell keine Macke hat.


    Auch damit CorrErr+ alle halbe Minute an 03:01.0, aber nie an 04:00.0.

    Das ist die Verbindung PCI bridge -> Cine!


    Auf der Verbindung PCI bridge (02:00.0) Mainboard gibt es keine Fehler. Das Mainboard ist also endgültig raus!

    Wobei das freilich keine in der Praxis brauchbare Lösung ist.

    Auch sind IMHO die CorrErr immernoch viel zu häufig.


    Erstaunlich finde ich, dass die auch nur noch in einer Richtung auftreten.

    Da hab ich aber auch keine rechte Idee, was das soll. Evtl. hängt es auch mit der Richtung der Datenmenge zusammen und ändert sich, wenn man ein CI betreibt.


    Eine Vermutung wäre , das das ext Board dolmetscht und sich so Teiln. A und B deutlich verstehen können.

    PCIe ist kein BUS im klassischen Sinne mehr. Es gibt immer nur noch Punkt zu Punkt Verbindungen zwischen zwei Geräten.

    Das ext Board baut eine PCIe-Verbindung mit dem Mainboard auf und eine andere mit der Cine.

    Mainboard und Cine kommunizieren also nicht mehr mit einander, was die Hardware-Ebene angeht.


    Bei HDMI ist es prinzipiell genau so. Wenn man einen HDMI-Extender zwischen zwei Geräte schaltet, baut jedes der Geräte eine Verbindung mit dem Extender auf (auch wieder nur die Hardware-Ebene betrachtet).

    Mein neuer Fernseher lässt sich nicht mit meinem einen Notebook per HDMI verbinden. Da gibt es zwar kurz mal ein paar Bild-Brocken, dann wird es Schwarz.

    Mit einem dazwischen geschalteten HDMI-Extender geht es aber einwandfrei.


    Ich schätze das wird hier so ähnlich liegen.


    Gibt es eigentlich einen Grund für die Fixierung auf Asrock als Hersteller?

    Wäre es nicht sinnvoller gewesen mit einem Board eines anderen Herstellers zu testen?

    Wenn man was vergleichbares sucht, wird die Auswahl eng. Die Marktnische hat Asrock fast allein besetzt.

    Und die Probleme wurden auch auf Boards von anderen Herstellern berichtet (mindestens ASUS).


    Ausserdem war in all den Jahren, wo ich mich mit so PC-Problemen rum schlage nie der Mainboard-Hersteller die Ursache.

    Es war immer auf einen speziellen Mainboard-Typ, den verwendeten Chipsatz (teilweise auch alle Chipsätze eines Herstellers), einzugrenzen, aber nie auf den Mainboard-Hersteller.

    Gruss
    SHF


  • PCIe ist kein BUS im klassischen Sinne mehr. Es gibt immer nur noch Punkt zu Punkt Verbindungen zwischen zwei Geräten.

    ist allg. bekannt, habe hier auch nichts anderes behauptet.

    Das ext Board baut eine PCIe-Verbindung mit dem Mainboard auf und eine andere mit der Cine.

    Mainboard und Cine kommunizieren also nicht mehr mit einander

    entweder falsch gelesen oder falsch verstanden.

    Mit Dometscher meinte ich die PCI-Brigde auf dem Extender die als "man in the middle" zwischen der DD-Brigde und dem MB-Brigde steht. Beim Bus würde nichts gedolmetscht, sondern durch/weiter geleitet. Hier wird empfangen, verstanden, und neu versendet.

    Zumindest, wenn man ein low-profile Gehäuse verwenden und mehrere Empfangskarten einbauen möchte.

    einen Vorteil hätte das Extension Board. Bei großen low profil Geräten (mit Platz in der Breite) kann man das Bord vertikal befestigen und könnte sogar die Full-HD FF so low profil flachlegen. Bei Mini itx ist manchmal im großen Gehäuse noch Platz.