I2C Timeouts mit ddbridge

  • Hi,

    kannst Du das mal stat dem rsync übers Netzwerk versuchen, dann könnte man zumindest die HDD/SSD's bzw SATA ausschließen.

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

    CU

    9000h

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

  • Hi,

    kommt eigentlich noch

    Mar 29 17:23:19 vdr3 kernel: [ 334.170901] CMCI storm detected: switching to poll mode

    Mar 29 17:28:20 vdr3 kernel: [ 634.723167] CMCI storm subsided: switching to interrupt mode


    vielleicht auch noch

    Code
    mce: [Hardware Error]: Machine check events logged

    koennte auch ein "DIMM enters a degraded state by experiencing correctable errors" sein


    CU

    9000

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

  • Deshalb auch meine Frage nach der Stromversorgung.


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

    Ich betreibe das System mit einer Pico-PSU und habe damit eigentlich sehr gute Erfahrungen gemacht.

    Kann es aber zur Sicherheit noch mit einer "großen" PSU testen.


    Bei dem Test mit Spannung am Power-Stecker der DD-Karte zeigte lspci immer noch AuxPwr- für diese an. Sollte das nicht auf AuxPwr+ gehen?

  • kommt eigentlich noch

    Mar 29 17:23:19 vdr3 kernel: [ 334.170901] CMCI storm detected: switching to poll mode

    Mar 29 17:28:20 vdr3 kernel: [ 634.723167] CMCI storm subsided: switching to interrupt mode

    Nein, was aber an "mce=no_cmci" liegen kann.

    mce: [Hardware Error]: Machine check events logged

    [ 0.097322] mce: [Hardware Error]: Machine check events logged

    [ 0.097326] mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank 4: e600000000020408

    [ 0.097335] mce: [Hardware Error]: TSC 0 ADDR fef5a8c0

    [ 0.097343] mce: [Hardware Error]: PROCESSOR 0:506c9 TIME 1554834203 SOCKET 0 APIC 0 microcode 36

  • Bei dem Test um den Fehler zu provozieren läuft immer nur Live-TV (im Transfer-Mode, da ja keine FF-Karte im System ist), und das Problem tritt immer mit dem Device auf, von dem das Live-Signal geholt wird.

    Also nur ein Live-Kanal und kein EPG-Scan im Hintergrund?

    Wenn es da schon Fehler gibt ist es schlecht, das ist ja praktisch der minimal Lastzustand.


    Es ging mir darum, ob die Fehler durch das Wechseln der Transponder vermehrt auftreten. Das könnte auf die Stromversorgung hin deuten.

    Oder ob es mit der Anzahl an Aufnahmen, die über die Karte gehen schlimmer wird.



    Ich betreibe das System mit einer Pico-PSU und habe damit eigentlich sehr gute Erfahrungen gemacht.

    Kann es aber zur Sicherheit noch mit einer "großen" PSU testen.

    Auch ich verwende eine Pico-PSU und halte die generell für zuverlässig.


    Problematisch sind da aber bei mehreren Zusatzgeräten die Kabelpeitschen. Das geht dann alles an einen kleinen Stecker an der Pico-PSU. von den Übergangswiderständen ist das nicht ideal.


    Dann sind die Steckernetzteile meistens nicht geerdet. Das kann Probleme bereiten, weil die SAT-Antenne geerdet sein sollte. Das kann zu Ausgleichsströmen über die Sat-Leitungen und damit zu Störungen führen.

    Die PCIe x1 Slots haben auch recht wenige Massepins, durchaus denkbar, dass es sich auch auf die Verbindung auswirkt.


    Ein Test mit einem anderen "herkömmlichen" Netzteil ist IMHO nicht verkehrt, zumal es recht schnell durchführbar ist.


    Dabei auch darauf achten, dass alle Masse-Verbindungen verbunden sind. (Netzteil-Gehäuse, Computer-Gehäuse, Slotbleche, Mainboard an Gehäuse, ...)


    Bei dem Test mit Spannung am Power-Stecker der DD-Karte zeigte lspci immer noch AuxPwr- für diese an. Sollte das nicht auf AuxPwr+ gehen?

    Keine Ahnung ob sich das laut Spezifikation ändern soll.

    Letztendlich sind das AFAIK aber alles nur Register auf der DD-Karte und die zeigen das an, was der Hersteller rein programmiert.


    Meine DVB-Sky zeigt übrigens auch AuxPwr- an, obwohl sie ohne Stecker nicht gescheit läuft.

    Code
    02:00.0 Multimedia video controller: Conexant Systems, Inc. CX23885 PCI Video and Audio Decoder (rev 04)        Subsystem: Device 4254:0952[...]                DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-

    Gruss
    SHF


  • Ah, so that would be 40MB/s, which may be too slow.

    When I run the rsync test that provokes the error, the data transfer rate is almost 100MB/s. The writing on the remote host goes to an SSD, so the Gigabit-Ethernet is probably the limiting factor.

    OK. I only have a couple of rather full spinning drives at the vdr end and rsync doesn't accept either /dev/zero or /dev/null as source or destination so cannot stress the network further.


    Regards,


    Richard

  • Ich habe jetzt mal folgende Änderungen vorgenommen:


    - VDR wird mit -D0 gestartet, somit definitiv kein EPG-Scan und damit keine Kanalumschaltungen während des Tests.

    - Die an der DD Cine S2 V7A angeschlossenen DuoFlex CI und DuoFlex C/C2/T/T2/ISDB-T Erweiterung abgesteckt.

    - Anstatt der PicoPSU ein "großes" Netzteil angeschlossen.

    - Den Stromversorgungsstecker der Cine S2 V7A an das Netzteil angeschlossen.


    Auch in dieser Konstellation treten die CorrErr+ bei der ddbridge und auch der Gegenstation ohne sonstiges Zutun (also kein rsync und kein Umschalten) nach einiger Zeit auf. Starte ich den rsync, so tritt der I2C-Fehler auch hier nach wenigen Sekunden auf.


    Ich glaube, damit dürfte die Theorie, dass es an der Stromversorgung oder dem EPG-Scan liegt, widerlegt sein.

  • Ah, so that would be 40MB/s, which may be too slow.

    When I run the rsync test that provokes the error, the data transfer rate is almost 100MB/s.

    Was passiert denn bei dir mit rsync und --bwlimit=40M ?

    Nur 40% wäre ja schon mal besser als aufgehängtes PCIe/Cine.

  • Ich habe DD jetzt mal auf diesen Thread aufmerksam gemacht.

    gibt es dazu schon Feedback?.

    Da ja USB letztendlich auch am PCIe hängt (über die Bridges) und USB + NIC keine Fehler bereitet, bleibt als Verursacher nur die DD übrig. Da außer dem VDR Forum auch in anderen Foren und Groups von I2C Timeouts berichtet wird, scheint das auch nicht auf ein spezielles MB Problem hinzudeuten. Das klingt alles irgendwie nach einem Designfehler der DD V7. Ich betreibe eine ältere DD Cine seit mehreren Jahren im Streamserver im Dauerlauf. I2C ist mir dort noch nie aufgefallen.

  • Ich glaube, damit dürfte die Theorie, dass es an der Stromversorgung oder dem EPG-Scan liegt, widerlegt sein.

    Es war aber wichtig das auszuschliessen.


    Da ja USB letztendlich auch am PCIe hängt (über die Bridges) und USB + NIC keine Fehler bereitet, bleibt als Verursacher nur die DD übrig. Da außer dem VDR Forum auch in anderen Foren und Groups von I2C Timeouts berichtet wird, scheint das auch nicht auf ein spezielles MB Problem hinzudeuten. Das klingt alles irgendwie nach einem Designfehler der DD V7.

    Das sehe ich genau so.

    Ich hatte das schon länger befürchtet, wollte aber nicht voreilig der Karte die Schuld zu schieben, bevor nicht alles andere ausgeschlossen ist.


    Ein anderes Mainboard ist IMHO daher auch keine wirkliche Lösung. Das kann gehen oder auch nicht, reines Glücksspiel.

    Wirklich helfen kann da wohl nur DD, wenn man die Karten weiter verwenden will.


    Ich betreibe eine ältere DD Cine seit mehreren Jahren im Streamserver im Dauerlauf. I2C ist mir dort noch nie aufgefallen.

    Bei DD gibt es etwa 10 unterschiedliche Firmwares in deren Paket, die werden je nach PCI-ID der Karte verwendet.

    Durchaus möglich, dass da nur einige Karten betroffen sind.


    Es könnte Sinn machen es mal mit Statistik zu versuchen und funktionierende bzw. problematische Mainboard-Karten-Kombinationen sammeln. Der Test ist einfach und die Karten sind hier recht beliebt. Wenn man genug zusammen bekommt, sieht man vielleicht irgendwelche Zusammenhänge.

    Gruss
    SHF


  • gibt es dazu schon Feedback?.

    Dort meint man, es läge wohl an der Versorgungsspannung. Was aber mit meinem heutigen Test wohl widerlegt ist.

    Bleibt lediglich noch das Motherboard. Da werde ich mir wohl zum endgültigen Beweis, dass der Fehler an der Cine S2 V7A liegen muss, eines von einem anderen Hersteller besorgen müssen...

Jetzt mitmachen!

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