I2C Timeouts mit ddbridge

  • Das Modul dvb-core.kopasst nicht zu der Version gegen die smipcie.ko gebaut worden ist. Kontrolliere noch einmal die Module (der externe dddvb-0.9.36 Treiber z.B. installiert seine Version von dvb-core.ko).


    Das war extern versorgt.

    Wenn es nur über den PCIe Slot auch ginge wäre das Thema "Spannung" endgültig geklärt.

    Helmut

  • Wenn du Vorschläge für Tests hast, kann ich die gerne durchführen.

    die Tests mit den eigenen Hausmittlen hattest Du ja schon gemacht (Spannung PCIe, Taktrate) usw. Mehr wird da ohne spezielles Equipment nicht möglich sein. Vielleicht liest jemand von den Verdächtigen mit und könnte sich da einen Reim drauf machen.

  • Die DD-Module waren anscheinend in der initrd, so dass ich die erst neu erzeugen musste.

    Inzwischen geht es und der Test mit rsync (wohlgemerkt auf dem J3455M Motherboard, denn das ist ja das Problematische) ergab keinerlei Fehler! Nicht einen einzigen CorrErr+, weder auf dem Device, noch auf der Gegenstation.

    Wobei der Test ca. eine Stunde lief.

    Es geht also doch!


    lspci -s 02:00.0 -vv:

    lspci -s 00:13.0 -vv:

  • da es aber im praktischen Betrieb keine Probleme gibt ist die Frage, ab wann es problematisch wird. Ein detektierter Fehler der das Flag setzt, wird nicht das Problem sein. Hier sind diese Fehler auch bekannt --> https://www.kernel.org/doc/Doc…ion/PCI/pcieaer-howto.txt und wohl üblich.

    Schwer zu sagen, ab wann es problematisch wird.


    Wenn man dieser Seite trauen kann, werden die Fehler durch eine erneute Übertragung behoben.

    Diese kosten natürlich unnötig Bandbreite und das wird man irgendwann merken.


    Wahrscheinlich wird es aber schon früher zu Problemen kommen und zwar, wenn eine Übertragung mehrfach hintereinander scheitert.

    Die Puffer sind in den Geräten sind nicht besonders gross, da könnte es schon nach ein paar Fehlversuchen eng werden.

    Leider geben die Flags nicht an, wie oft der Fehler aufgetreten ist, sondern nur, dass er (mindestens einmal) aufgetreten ist.


    Aber selbst ein Pufferüberlauf ist eigentlich kein Grund, dass die Karte komplett aussteigt.


    Meine Vermutung geht stark Richtung Timing-Problem.

    Die Karte muss synchron zum Referenztakt von 100MHz den Datentakt von 2,5GHz erzeugen. Das scheint auf einem FPGA nicht ohne Tücken zu sein.

    Wenn man nach diesen PCIe-Parametern sucht, stösst man immer wieder auf FPGA-Howtos bezgl. korrektem PCIe-Timing.

    Wenn der Oszillator stolpert, sind ruck-zuck ein paar Datenpakete hinüber und wenn die Störung zu gross wird hängt sich die Karte auf.


    100MHz gehen noch, wer will und in entsprechendes Oszilloskop hat, kann ja mal versuchen, ob man auf dem RecCkl-Signal beim J3355M was sieht.



    ... aber zurück zu den Fehlern.

    Wenn es alles richtig läuft, sollten die überhaupt nicht auftreten. Auf keinem meiner Computer konnte ich welche beobachten.

    Ein gutes Zeichen sind sie zudem nicht, besonders wenn sie regelmässig auftreten. Das es bedeutet, das irgendwas grenzwertig arbeitet.

    Quote

    Errors in the low-level packets are not only a performance issue (retransmissions are a waste of bandwidth). With properly designed hardware, there is no reason for their appearance at all, so their very existence indicates that something might be close to stop working.


    Wo die Grenze zwischen geht und geht nicht mehr in der Praxis liegt, hat kls schön gezeigt. Wir sitzen ziemlich genau drauf.

    Beim J4105M geht es, beim J3355M geht es nicht und der Unterschied in der Fehlerrate ist nicht so gross.



    neben den unterschiedlichen devices auch max payload, linkspeed, Powerlimit, devcap, linkctl, usw.

    Die ...Cap-Zeilen kann man ignorieren, die geben nur die Fähigkeiten des Devices an.

    Der aktuelle Status ist in ...Sta zu finden. Da sind dann die Abweichungen nicht mehr so gross.

    Gruss
    SHF


  • Was die wiederholte Übertragung bei Fehlern auf dem PCIe betrifft, das gilt evtl. dann nicht für Message-Signaled-Interrupts (MSI),

    zumal diese auch nicht bestätigt werden. In dem Fall würde der Kernel auch irgendwann nicht behandelte Interrupts monieren

    oder die hardware evtl auf den Treiber warten..

  • Nachtrag zum J4105M Board: Der Eintrag "options ddbridge msi=0" in /etc/modprobe.d/ddbridge.conf scheint wohl nicht nötig zu sein. Zumindest konnte ich weder mit noch ohne ihn einen I2C-Fehler mittels rsync hervorrufen. Bis auf die gelegentlichen CorrErr+ an der PCIe-Gegenstation (die ohne erkennbare Auswirkungen sind) läuft es nach wie vor stabil.

  • Klaus, auch wenn das jetzt off-topic ist: Nutzt Du die integrierte Intel-Grafik oder hast Du eine Nvidia-Grafikkarte am laufen? Kannst Du da mal einen Vergleich ziehen? Wie unterscheidet sich die Bildqualität der Intel-Grafik zwischen J4105M und J3355M, und inwieweit siehst Du bei beiden einen Unterschied zur Nvidia-Karte?

    VDR 1: Silverstone LC20, Cougar A300/R, Asrock J4105B-ITX, WinTV DualHD, WD10EACS; Atric-IR-Einschalter. SW: Xubuntu 19.04 per SSD
    VDR 2: ACT-620, Asrock B75 Pro3-M, Celeron G540, passive Asus GT610, Cine CT V6, KNC-One DVB-C, Atric-IR-Einschalter. SW: Xubuntu 18.04 per SSD

  • Ja, ich nutze die On-Board Grafik. Das war mit ein Grund, warum ich diese Art von Board gewählt habe.

    Einen Unterschied zwischen den beiden Boards kann ich nicht wirklich erkennen. Ich finde das Bild in beiden Fällen sehr gut.

    Mit einer Nvidia-Karte hab eich keine Erfahrung (auch keine hier zum Probieren).

  • Was die wiederholte Übertragung bei Fehlern auf dem PCIe betrifft, das gilt evtl. dann nicht für Message-Signaled-Interrupts (MSI), zumal diese auch nicht bestätigt werden.

    Nach meinem Verständnis werden die Wiederholungen auf der Hardware-Schicht ausgelöst.

    Das heisst, wenn die Message-Signaled-Interrupts in Datenpaketen verschickt werden, sollten die auch erneut übertragen werden.


    Mein Wissen stammt aber aus Sekunderquellen, bei derartigen Detailfragen müsste man sich selber mal durch die Spezifikation arbeiten.


    Nachtrag zum J4105M Board: Der Eintrag "options ddbridge msi=0" in /etc/modprobe.d/ddbridge.conf scheint wohl nicht nötig zu sein.

    Die Einstellung ist AFAIK auch nur bei fehlerhaften ACPI-, MSI-, Wasauchimmer-Tabellen im BIOS sinnvoll.

    Gruss
    SHF


  • Die Einstellung ist AFAIK auch nur bei fehlerhaften ACPI-, MSI-, Wasauchimmer-Tabellen im BIOS sinnvoll.

    da sehe ich auch so. WIe in MSI-HOWTO.txt beschrieben sind interrupt requests über MSI u.a deshalb effektiver, da sie eindeutig einem Gerät zugeordnet werden können. Bei der anderen Methode mit Signalisierung über Hardware-Pins (msi=0) kann es sein das dieser Pin von mehreren Geräten verwendet wird und deshalb unnötigerweise die Interrupt Service Routinen (ISR) aller dieser Geräte aufgerufen werden (müssen). Wenn damit keine Pobleme auftauchen ist MSI die bessere Wahl. Grundsätzlcih sollte es aber mit jeder Einstellung funktionieren.


    Beim ddbridge Treiber ist übrigens die default Einstellung für MSI auf github und im Kernel etwas unterschiedlich. Auf github (0.9.37) ist MSi per default aktiviert, im Linux Treiber (0.9.33) hängt es vom Wert von DVB_DDBRIDGE_MSIENABLE ab, dieser ist im default "N"also deaktiviert. Dazu gibt es auch eine kurze Beschreibung:

    SATA war zwar hier noch nicht das Thema, wir wissen inzwischen aber das msi=0 in der Kombination von J3455M und V7A nicht hilft.

    Helmut

  • Bei der anderen Methode mit Signalisierung über Hardware-Pins

    Gerade zum Thema MSI bei PCIe gibt es wohl viele Missverstaendnisse.


    Zunaechst mal werden alle Interrupts bei PCIe ueber Messages signalisiert. Es gibt schlichtweg keine weiteren Leitungen neben den PCIe-Lanes, ueber die solche Informationen uebertragen werden koennten.

    Die erste PCIe-Version war nun so designt, dass sie softwaremaessig kompatibel zu "normalem" PCI war, somit gab es bis zu 4 "legacy" Interrupts pro PCIe-Slot, die auch fuer den ganzen "Bus" (PCIe-Root-Complex) geshared werden.

    In spaeteren PCIe-Versionen kam man nun auf die Idee, dass man neben den ohnehin vorhandenen Messages als Option auch mehr als diese 4 Interrupts signalisieren koennte (bis zu 32 in 2er-Potenz-Schritten bei MSI, flexibler bei MSI-X), kostet halt quasi (an Hardware) nix. Diese Zusatz-Interrupts werden nun nicht geshared, es gibt aber keine Garantie, dass man die angeforderte Anzahl auch zugeteilt bekommt. Ein PCIe-Root-Complex unterstuetzt halt nur eine begrenzte Anzahl an Interrupts (die er ja zunaechst mal wieder ueber regulaere Leitungen an einen Interrupt-Controller signalisieren muss), und ein PCIe-"Bus" kann ja ueber Bridges recht viele PCIe-Slots haben. "Neuerdings" muessen die Interrupt-Messages nicht mehr im PCIe-Root-Complex enden, sondern koennen - per memory-mapped-IO, uebersetzt vom Root-Complex - auch direkt in Registern eines Interrupt-Controllers enden. Somit braucht man keine dedizierten MSI-IRQ- Leitungen vom Root-Complex zum Interrupt-Controller mehr, die vorhandenen IRQ-Anzahl kann im Zweifel zwischen mehrenen PCIe-Bussen flexibel aufgeteilt werden, eine Obergrenze (Adressen im Interrupt-Controller) gibt es aber immer noch.


    In der Praxis ist es nun so, dass normalerweise keine Interrupts geshared werden, da selten mehr als 4 PCIe-Karten pro Bus benutzt werden. Auch kenne ich keine DVB-PCIe-Karte, die mehr als einen Interrupt benutzt (einfach weil der Treiber eh mit der Tatsache zurechtkommen muss, dass er nicht mehrere Interrupts (Vektoren) zugeteilt bekommt und alternativ eine single-IRQ-Option implementieren muss). Somit gibt es in der Praxis nur selten einen (meist nur kleinen) Vorteil von MSI(-X). Aber gutes Treiber-Design nutzt jedoch auch diesen potentiellen kleinen Vorteil durch Aktivierung von MSI(-X).


    Frueher (in aelteren Kernel-Versionen) war es in LInux noetig, dass ein Treiber sich entscheiden muss, ob er legacy- oder MSI(-X)-Interrupts nutzen will. Das ist heutzutage (bei aktuellen Kerneln) nicht mehr so. Ein vernuenftiger Treiber hat die Modul-Option zur Aktivierung von MSI also heutzutage nicht mehr.


    Leider gibt es einige (buggy) PCIe-Root-Complex-Implementierungen, die nicht gleichzeitig legacy- und MSI-Interrupts unterstuetzen. Auch kann man MSI im Kernel deaktivieren. Nur fuer diese Faelle ergibt eine Modul-Option fuer MSI Sinn.


    Zusammenfassend ist so eine MSI-Kernel-Modul-Option heutzutage nicht mehr notwendig und ergibt auch in aelteren Kernel-Versionen nur als Workaround fuer Hardware-Fehler Sinn. Performance-Unterschiede oder auch anderes Verhalten gegenueber PCIe-AER (wie in diesem Thread diskutiert) wird man nicht feststellen.


    Gruss,

    S:oren

  • Um das Ganze abzuschließen habe ich nach Rücksprache mit der Geschäftsleitung von DD einen VDR zusammengestellt, mit dem das Problem zuverlässig reprodizierbar ist und ihnen geschickt. Zusätzlich habe ich die DVBSky S952 v3 beigelegt, zum Beweis, dass es auch ohne Fehler geht ;-).


    Mal sehen, ob sie damit den Fehler beheben können...

  • Ich ziehe jetzt schonmal den Hut vor euch allen.:thumbup:

    Ich verfolge wie wahrscheinliche andere den Thread seit Wochen nur um zu schauen wie es weiter geht...

    Auch wenn ich die Karte aktuell nicht mehr nutze, würde ich mich freuen wenn DD einen fix dazu herausbringt.

    VDR_1:

    Asus J3455-M, GT 710, SSD 240GB, 8GB DDR3, 1x DvbSky S950 with yavdr-ansible (testing)

    VDR_2:

    AsRock J3455, GT 710, SSD 120GB + SATA 400GB, 8GB DDR3, 1x DvbSky S952 with yavdr-ansible (testing)

    VDR_3_Testing:

    AtomiPi with Intel Atom x5-Z8350, 2GB DDR3, 16GB eMMC, 1x Sundtekt DVB-S with yavdr-ansible (testing)


  • ... nach Rücksprache mit der Geschäftsleitung von DD einen VDR zusammengestellt, mit dem das Problem zuverlässig reprodizierbar ist und ihnen geschickt...

    Wow, das nenne ich mal Einsatz - Respekt!

    MyVDR: yaVDR-Ansible - softhddevice-openglosd (ffmpeg 2.8) - epgd/epg2vdr - skindesigner estuary4vdr (adaptiert) - 1920x1080@50 Hz | kodi 18 - inputstream + amazon vod *broken*
    Aerocube M40 | 300W | ASRock H61M-GE | Intel G530 | Asus ENGT520 | 2 x TT-budget S2-3200 | ASRock Smart Remote (CIR) | 4 GB RAM | 120 GB SSD | 3 TB HDD

  • Gibt's hier schon Neuigkeiten?


    Stefan