I2C Timeouts mit ddbridge

  • Hi,

    bei meinem Asrock J4205-ITX

    Es ist eagl in wlehcer Reiehnfogle die Bchustebaen in Woeretrn vokrmomen. Huapstache der estre und leztte Bchustbae sitmmen.

  • Soeben kam im Log diese Meldung:


    kernel: [ 6046.137805] r8169 0000:01:00.0: invalid large VPD tag 7f at offset 0

    Das kommt bei meinem Arbeitsrechner auch.

    Ist mir aber eben erst aufgefallen. Probleme gibt es keine, auf dem System läuft aber kein VDR.


    Sieht hier genau so aus.

    r8169 am Arbeitsrechner, r8168 am VDR.

    Warum ich da den r8168 weiss ich nicht mehr. Wird aber einen Grund gehabt haben.


    Merkwürdig ist, dass der r8168 keine Firmware braucht. Da ist nicht mal was dazu erwähnt.

    Witziger weise laufen die Karten auch mit dem r8169 ohne Firmware. Das Phänomen ist mir vor Jahren mal aufgefallen.

    Es gibt eine Fehlermeldung beim Laden des Moduls, gehen tut es aber trotzdem.


    Das ganze sagt aber nicht unbedingt was aus. Es könnte sich um unterschiedliche Chips handeln, es gibt da so viele Varianten und Versionen.


    Glaub zwar nicht, dass es dir viel hilft ...

    Wirklich sinnvoll ist es nur die Ausgaben der DD- und der Realtekkarten auf möglichst ähnlichen Boards zu vergleichen.


    Ein PCIe-Slot wäre zwar frei, der Einbauplatz ist aber belegt durch eine Receiver-Karte.

    Könnte man die Huckepackkarte nicht testweise ausbauen oder verlängern?

    Eine andere Netzwerkkarte wäre die einfachste Option das Problem einzugrenzen.

    Ist auf dem Board(s) ein ASmedia 1083 als PCIe to PCI Bridge?

    Ist nicht drauf.

    Ausserdem hat nur die Rev. 01 den Fehler und die wird seit mindestens Mitte 2013 nicht mehr verbaut.

    Bei neueren Mainboards sollte man sicher sein.

    Meine beiden mit Rev. 03 laufen auch seit Jahren zuverlässig.



    Bei der Suche bin ich zufällig auf diesen Artikel gestossen:

    Der r8169-Treiber für den Realtek-Netzwerkchip funktioniert bis zur Kernelversion 4.16 nicht immer korrekt. Es können Timeouts entstehen, die Netzwerkkarte zwischen den Zuständen link up/link down wechseln sowie Bandbreitenprobleme oder sogar Systemabstürze vorkommen.


    Eine Lösung des Problems besteht in der Installation des offiziellen r8168 Treibers von Realtek statt dem r8169 des Linux Kernels. Er kann aus Fremdrepositories nachinstalliert oder selbst kompiliert werden. Alternativ kann der Kernel auf Version 4.17+ aktualisiert werden.


    [...]

    Gruss
    SHF


  • Witziger weise laufen die Karten auch mit dem r8169 ohne Firmware

    Die Firmware die nachgeladen wird dürfte auch nur ein Patch sein und keine Vollständige die zum Betrieb notwendg ist.

    Mein J3455-ITX läuft auch ohne den fw-patch problemlos (abe auch ohne DD) - hab ihn einfach nie installiert.

    Mit dmesg | greo r816 sehe ich diese Melung (aus r8169.c):

    netif_warn(tp, ifup, tp->dev, "unable to load firmware patch %s (%d)\n",


    Helmut

    HelmutB passed unfortunately away on July 21, 2022 ... RIP 🖤

  • Ich habe jetzt mal so eine Karte bestellt

    besteht denn das Platzproblem nicht mehr? Zur Diagnose wäre es sicher notwendig, wenn alle beteiligten Geräte im System wären.

    Wenn Dein Gehäuse Platz dafür bietet, könntest Du einen PCIe Expander verwenden.

    So was in der Art --> https://www.ebay.com/itm/PCI-E…80bb8b:g:W18AAOSwsq1cZ76G

    Vielleicht nicht gerade den verlinkten, das Transfer Kabel wäre mir zu lang und vielleicht auch wieder fehleranfällig. Aber etwas mit 15-20cm sollte bestimmt funktionieren.

  • Heute wurde die Intel-Netzwerkkarte geliefert. Hab sie eingebaut, den onboard Netzwerk-Adapter im BIOS ausgeschaltet, die neue Karte konfiguriert und den Test gestartet. Bereits nach ein paar Sekunden trat exakt der gleiche Fehler wieder auf.


    Ich fasse jetzt mal meine bisherigen Erkenntnisse zusammen:


    1. Betreibt man auf einem ASRock J3455M-Motherboard mit einer DD Cine S2 V7A einen VDR, und macht parallel dazu einen 'rsync' großer Dateien (z.B. das VDR-Videoverzeichnis) über das Netzwerk auf einen anderen Rechner, so kommt es nach kurzer Zeit zu I2C-Timeouts. <edit>'options ddbridge msi=0' ist in /etc/modprobe.d/ddbridge.conf eingetragen.</edit>


    2. Das Problem tritt nicht auf, wenn zwar der ddbridge-Treiber geladen ist (und der 'rsync' läuft), aber kein VDR läuft, da dann ja auch keine Zugriffe auf die DD-Devices stattfinden. Ich kann auch den VDR starten und nach einiger Zeit wieder beenden und dann erst den 'rsync' laufen lassen, was auch keine Probleme macht.

    <edit>Ebenfalls tritt das Problem nicht auf wenn der 'rsync' (bei laufendem VDR) auf eine lokale (externe) USB-Platte erfolgt.</edit>


    3. Das Problem ist nicht auf ein bestimmtes Exemplar des Motherboards beschränkt (habe es mit drei Examplaren des J3455M probiert).


    4. Es ist nicht auf ein bestimmtes Exemplar der DD Cine S2 V7A beschränkt (habe mit drei verschiedenen getestet).


    5. Es ist unabhängig von der BIOS-Version (getestet mit Version 1.20, 1.50, 1.60 und 1.90).


    6. Es ist unabhängig von der Kernel-Version (getestet mit Kernel 4.12.14 und 4.19.32).


    7. Es tritt sowohl mit dem onboard NIC (r8168) als auch einem Intel NIC (e1000e) auf.


    Nachdem nun schon einige mögliche Fehlerquellen ausgeschlossen wurden, bleiben als mögliche Ursachen eigentlich nur


    A. Ein Hardware-Design-Fehler auf dem J3455M Board.


    B. Ein Hardware-Design-Fehler auf der DD Cine S2 V7A.


    C. Ein Fehler in der DD-Firmware.


    D. Ein Fehler im ddbridge-Treiber.


    Bevor ich mir jetzt ein anderes Motherboard besorge und damit teste, wäre es nett, wenn jemand hier, der einen VDR mit DD Cine S2 V7A und einem *anderen* Board als das J3455M betreibt, den hier beschriebenen Test machen könnte.

  • Ein USB Netzwerkadapter iwe von vdr_rossi hier vorgeschlagen wäre zumindest eine Möglichkeit von der PCI Bridge wegzukommen.

    Wenn du zufällig noch einem USB WLAN-Stick herumliegen hast wäre er für einen 1. Test möglicherweise auch brauchbar.


    Greift ddbridge/Cine eigentlich von sich aus auf das Netzwerk zu ? (ich wüsste jetzt aber gar nicht warum das sein sollte).

    Helmut

    HelmutB passed unfortunately away on July 21, 2022 ... RIP 🖤

  • Testen kann ich mangels DD-Karte leider nicht, aber trotzdem eine Frage dazu:

    Rsync läuft auf ein, per nfs, samba oder was-auch-immer, gemountetes Verzeichnis, oder rsync direkt übers Netzwerk?

    Keine Ahnung ob das einen Unterschied macht, aber besser man testet es auch genau so.


    kpti=off nopcid nopti nospectre_v1 nospectre_v2 nospec_store_bypass_disable pr_spec_disable_noexec

    Mit den Optionen sollten eigentlich alle Spectre-Geschichten deaktiviert sein. (Das hoffe ich zumindest mal.)

    Ist einen Versuch wert, denke ich.


    Da es auch mit einer anderen Netzwerkkarte zu den Problemen kommt, könnte man noch an den PCIe-Parametern drehen.

    Ich vermute, dass die Cine wegen der vielen Pakete von der Netzwerkkarte zu selten an die Reihe kommt um ihren internen Puffer ganz leer zu bekommen. Eine Weile geht das, aber irgendwann kommt noch ein Ereignis, der Puffer läuft über und die Karte oder der Treiber hängt sich (warum auch immer) auf.

    In dem Zusammenhang wäre es echt interessant, was die LED bedeutet.

    Meine Vermutung ist, die hat mit dem Füllstand des FIFO auf der Karte zu tun. Das würde passen.


    Das Problem trat so ähnlich schon bei den PCI-Karten auf. Bei den FF-Karten brachte ein erhöhen der PCI-Latency bei mir auch immer was an Stabilität. Mit der voreingestellten Latency konnten die Karten den internen Puffer nicht in einem Zug leeren, wenn er ganz voll war.


    An den PCIe-Parametern habe noch nicht rumschrauben müssen, kann also nicht so genau abschätzen was es bringt.

    Ich würde aber mal versuchen die MaxReadReq der Cine, nach dieser Anleitung, auf 4096 zu erhöhen.

    Man könnte auch noch versuchen die MaxReadReq Netzwerkkarte auf 512 zu senken.



    Eventuell könnte man auch die Priorität des DD-Treibers erhöhen.

    Ob das auf Kernel-Ebene geht weiss ich aber nicht.

    Gruss
    SHF


  • Rsync läuft auf ein, per nfs, samba oder was-auch-immer, gemountetes Verzeichnis, oder rsync direkt übers Netzwerk?

    Für den Test mache ich einen rsync direkt über das Netzwerk:


    rsync -av vdr3:/video .


    Ich habe aufgrund deiner Frage jetzt den rsync auch mal so gemacht, dass ich mich auf dem VDR-PC via ssh eingeloggt und auf ein dort via NFS gemountetes Volume kopiert habe. Damit lief der Test zwar relativ lange, aber nach einer knappen halben Stunde kam es wieder zu dem bekannten Fehler.

  • An den PCIe-Parametern habe noch nicht rumschrauben müssen, kann also nicht so genau abschätzen was es bringt.


    Ich würde aber mal versuchen die MaxReadReq der Cine, nach dieser Anleitung, auf 4096 zu erhöhen.


    Man könnte auch noch versuchen die MaxReadReq Netzwerkkarte auf 512 zu senken.

    Wenn ich gemäß dieser Anleitung


    setpci -s 02:00.0 68.w


    mache erhalte ich '0000'. Erwartet würde aber ein Wert wie '2936'.

Jetzt mitmachen!

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