I2C Timeouts mit ddbridge

  • Ich habe meine PCIe 1x/16x Riser genauer angesehen.

    Sei sieht genau so aus wie auf dem Bild in #184, darauf sind 4 runde Kodensatoren, 1 DC/DC Spannungswandler, 1 Spule und 1 Spannungsregler. Die Unterseite ist plan, mit 2mm Moosgummi sauber abgedeckt.

    Also nur Power, keine PCIe-Bridge.

    Helmut

  • Mal probiert den Kernel einfach ohne weitere Treiber zu verwenden?

    Hab den aktuellsten Kernel für mein System eingespielt (4.12.14-lp150.12.58-default), 'extra' aus /etc/depmod.d/00-system.conf entfernt und depmod -a gemacht (die beiden letzteren nur zur Sicherheit, hatte vermutlich keine Auswirkung). Damit kommt bei "modprobe ddbridge" im Log

    Code
    1. Apr 17 17:43:53 vdr3 kernel: [ 345.272791] cxd2099: module is from the staging directory, the quality is unknown, you have been warned.
    2. Apr 17 17:43:53 vdr3 kernel: [ 345.273708] ddbridge: unknown parameter 'msi' ignored
    3. Apr 17 17:43:53 vdr3 kernel: [ 345.273781] Digital Devices PCIE bridge driver, Copyright (C) 2010-11 Digital Devices GmbH

    und es wird nicht einmal ein /dev/dvb angelegt.

    "modinfo ddbridge" sagt, dass das die Version 0.5 ist, was vermutlich viel zu alt ist...

  • 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 hab's jetzt nochmal mit Kernel 4.19.32 versucht (hatte ich noch von Versuchen hier), mit dem der ddbridge Treiber 0.9.33 kommt.

    Der Fehler tritt damit genauso auf.

  • 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...

  • Post by seahawk1986 ().

    This post was deleted by the author themselves: Die Lösung von S:oren ist einfacher ().
  • 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...

  • Sehr interessant wäre auch noch ein entsprechender Test mit dem Octopus plus zugehörige Empfänger (#209).

  • 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.