I2C Timeouts mit ddbridge

    bei manchen Bios-en hat man die Möglichkeit, die PCIe Taktfrequenz und/oder die PCIe Link Spannung zu erhöhen/verringern. Vielleicht kann man das hier mal ganz moderat versuchen. Das Problem scheint wohl zu sein, das Sender und Empfänger sich nach einiger Zeit nicht mehr verstehen (evtl. Jitter?) Vielleicht können Parameteränderungen helfen

    Vielleicht noch einmal als Anregung z.B. TP-Link UE300 (Herstellerinfo auf der Seite ganz unten).

    Den gibt es auch mit USB3-Hub aLs UE330 und wird zumindest ab Kernel ab 4.15 von drivers/net/usb/r8152,c unterstützt.

    Helmut

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

    Einmal editiert, zuletzt von HelmutB ()

    Zitat von 9000H

    did you have the latest Intel microcode on your system?

    Following the instructions from here I get


    How can I tell if this is the latest microcode version?

    And should I be worried about that "Hardware Error" message?

    Zitat von HelmutB

    Da musst du dich verschaut haben - der TP-LINK UE300 ist ein USB-3.0- 10/100/1000Mbit/s-Gigabit-Ethernet-Adapter.

    Sorry, mein Fehler.


    Ich hatte es zwischenzeitlich mal mit einem USB-WLAN-Adapter probiert, damit kam ich zwar ans Netzt, aber als ich den rsync gestartet habe, brach die Verbindung komplett zusammen. Hab das dann nicht weiterverfolgt.


    Ich hab jetzt nochmal den Intel NIC reingesteckt um zu sehen, welchen MaxReadReq Wert der hat. Dort sind es 512 Byte, also dürfte die Theorie, dass die 4096 Byte des Realtek zu viel sind, wackeln.

    Bleibt noch die Theorie, dass die 512 des ddbridge zu wenig sind.

    Die 4096 Bytes beim NIC und die 512 Btes bei der DVB-Karte (DvbSky) habe ich auch, das dürften eher Standardwerte sein die normalerweise auch funktionieren.


    Die Idee mit dem USB-LAN ist, dass du dann den Onboard NIC im Bios komplett abschalten kannst (wenn dein Bios noch so aussieht wie im User-Manual von Asrock) und die DDs dann ungestört sind.


    Helmut

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

    Ich habe jetzt mal ein kleines Script gemacht, welches die Bytes mit setpci einzeln ausgibt:

    Damit erhalte ich bei der ddbridge

    Durch Vergleich mit den Bytes des NIC und etwas intuitives Raten habe ich mal das Byte 0x99 von 0x20 auf 0x50 geändert und damit tatsächlich etwas erreicht:

    Code
    root@vdr3:/home/kls > lspci -s 02:00.0 -vvv | grep -e MaxRead -e ^0 
02:00.0 Multimedia controller: Digital Devices GmbH Cine V7
                        MaxPayload 128 bytes, MaxReadReq 512 bytes
root@vdr3:/home/kls > setpci -s 02:00.0 99.b=50                    
root@vdr3:/home/kls > lspci -s 02:00.0 -vvv | grep -e MaxRead -e ^0
02:00.0 Multimedia controller: Digital Devices GmbH Cine V7
                        MaxPayload 128 bytes, MaxReadReq 4096 bytes

    Ein anschließender rsync führte aber leider wieder zum Fehler.

    Was ich natürlich nicht weiß ist, inwieweit deise Änderung auch sofort in der ddbridge greift.

    Als Gegenprobe noch der Versuch, die 4096 beim NIC herunterzusetzen (hier ist es anscheinend das Byte 0x79):

    Leider tritt der Fehler auch damit auf.

    Die Fehler treten wohl schon im Link auf, da hat rjkm recht gehabt.

    Rumschrauben an den Timing-Werten ist also sinnlos!

    - Zumindest verstehe ich es so, dass diese "DevSta:" -Werte direkt von der Hardware kommen und das ist eine Ebene unter dem Busprotokoll.


    Die Link-Geschwindigkeit zu verringern ist wohn nicht möglich.

    2,5 GT/s ist schon Gen 1.0 und weniger geht AFAIK nicht.


    Gibt es im BIOS so was wie "spread spectrum" oder emv irgendwas?

    Das sollte man abschalten, weil es den Jitter erhöht.


    Man könnte noch schauen, ob das Problem auch bei anderen PCIe-Karten auftritt und so den Schuldigen eingrenzen (Mainboard vs. Cine). Siehe mein letzter Beitrag.


    Und unbedingt den Stromstecker an die Cine anschliessen, falls das nicht schon geschehen ist.

    Meine DvbSky läuft ohne auch nur teilweise und das obwohl sie an einem Multischalter hängt!

    Ich kenne den Aufbau der Cine zwar nicht im Detail, aber die LNB-Regler können beim ein- und umschalten schon ganz schöne Stromspitzen erzeugen. Unter Umständen können die auch Störungen auf der PCI-Bridge erzeugen. Da können die Übergangswiderstände auf dem Board und Slot schon was ausmachen.


    Da die Fehler nur unter Last auftreten, könnte man auch noch mal ein anderes Netzteil probieren, falls in beiden Aufbauten das gleiche steckt.

    Gruss
    SHF


    Hi,

    Code
    [    0.000000] kernel: microcode: microcode updated early to revision 0x32, date = 2018-05-11
[    0.000000] kernel: smpboot: Allowing 4 CPUs, 0 hotplug CPUs
[    0.066141] kernel: smpboot: CPU0: Intel(R) Pentium(R) CPU J4205 @ 1.50GHz (family: 0x6, model: 0x5c, stepping: 0x9)
[    0.066286] kernel: mce: [Hardware Error]: PROCESSOR 0:506c9 TIME 1551386069 SOCKET 0 APIC 0 microcode 32
[    0.068000] kernel: smp: Bringing up secondary CPUs ...
[    0.072660] kernel: smp: Brought up 1 node, 4 CPUs
[    0.072660] kernel: smpboot: Max logical packages: 1
[    0.072660] kernel: smpboot: Total of 4 processors activated (11980.80 BogoMIPS)
[    1.912677] kernel: microcode: sig=0x506c9, pf=0x1, revision=0x32
[    1.912864] kernel: microcode: Microcode Update Driver: v2.2.

    scheint bei Dir aelter zu sein


    CU

    9000h

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

    Zitat von mini73

    Hast du mal probiert, bei rsync mit --bwlimit die Bandbreite zu reduzieren? Die Angabe ist in KB/s.

    Mit --bwlimit=50M trat der Fehler nach wenigen Sekunden auf.

    Bei --bwlimit=10M läuft es anscheinend störungsfrei. Wenn ich parallel dazu folgendes mache

    Code
    lspci -vvv | grep -e CorrErr; setpci -s 02:00.0 CAP_EXP+0xa.w=0x000f; setpci -s 00:13.1 CAP_EXP+0xa.w=0x000f; echo; lspci -vvv | grep -e CorrErr; sleep 3; echo; lspci -vvv | grep -e CorrErr

    erhalte ich

    Die beiden CorrErr+ stammen von der ddbridge und der Gegensation. Es treten also anscheinend alle paar Sekunden CorrErr auf (mache ich nur 'sleep 2' ist noch kein Fehler da). Ohne den rsync bleibt es lange Zeit konstant bei CorrErr-. Aber ab und zu tritt ein CorrErr+ auf, manchmal nur bei der Gegensation, manchmal bei beiden.

    Irgend etwas stimmt also wohl auch ohne besondere Last nicht an der Kommunikation mit der ddbridge...

    Hi,

    passiert das auch wenn man local über lo traffic schiebt?

    Code
    </dev/zero ssh user@localhost 'cat > /dev/null'

    CU

    9000h

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

    Zitat von kls

    Die beiden CorrErr+ stammen von der ddbridge und der Gegensation. Es treten also anscheinend alle paar Sekunden CorrErr auf (mache ich nur 'sleep 2' ist noch kein Fehler da).

    CorrErr sollten gar nicht kommen.

    "alle paar Sekunden" ist IMHO also definitiv zu oft.


    Zitat von kls

    Ohne den rsync bleibt es lange Zeit konstant bei CorrErr-. Aber ab und zu tritt ein CorrErr+ auf, manchmal nur bei der Gegensation, manchmal bei beiden.

    Macht es einen Unterschied, ob nur Aufnahmen laufen oder ein EPG-Scan?


    Zitat von kls

    Irgend etwas stimmt also wohl auch ohne besondere Last nicht an der Kommunikation mit der ddbridge...

    Deshalb auch meine Frage nach der Stromversorgung.

    So merkwürdige Fehler, die unter Last schlimmer werden hängen erstaunlich oft damit zusammen.


    Ausserdem gehen langsam die Optionen aus, wenn es am Link direkt liegt.

    Da gibt es zwar Werte, die man theoretisch ändern könnte, ich habe aber noch nichts dazu gefunden, wie man da ran kommt.

    Gruss
    SHF


Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden