I2C Timeouts mit ddbridge

  • Sure,


    01:00.0 Multimedia controller: Digital Devices GmbH Cine V7

    Subsystem: Digital Devices GmbH Device 0024

    Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+

    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-

    Latency: 0

    Interrupt: pin A routed to IRQ 124

    Region 0: Memory at 91400000 (64-bit, non-prefetchable) [size=64K]

    Capabilities: [50] Power Management version 3

    Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)

    Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-

    Capabilities: [70] MSI: Enable+ Count=1/2 Maskable- 64bit+

    Address: 00000000fee02004 Data: 4022

    Capabilities: [90] Express (v2) Endpoint, MSI 00

    DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us

    ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 0.000W

    DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-

    RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-

    MaxPayload 128 bytes, MaxReadReq 512 bytes

    DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-

    LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Exit Latency L0s unlimited, L1 <1us

    ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-

    LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+

    ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-

    LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-

    DevCap2: Completion Timeout: Range A, TimeoutDis+, LTR-, OBFF Not Supported

    AtomicOpsCap: 32bit- 64bit- 128bitCAS-

    DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled

    AtomicOpsCtl: ReqEn-

    LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-

    Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-

    Compliance De-emphasis: -6dB

    LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-

    EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-

    Capabilities: [100 v1] Vendor Specific Information: ID=0000 Rev=0 Len=00c <?>

    Kernel driver in use: ddbridge

    Kernel modules: ddbridge


    Regards,


    Richard

  • Das war ja leider nicht so erfolgreich :(.


    Nach etwas lesen habe ich aber heute festgestellt, dass lspci auch Auskunft über den PCIe Kink gibt:

    DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-

    Die Zeile gibt an, ob es zu Fehlern gekommen ist und ob sie korrigierbar waren.


    Bei ras steht alles auf "-", das bedeutet keine Fehler.

    Bei kls sind korrigierbare Fehler aufgetreten:

    DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-

    Und die bei der DD Cine und auch der zugehörigen PCIe-Bridge. Man muss immer beide Seiten der Verbindung betrachten.

    Das muss nicht zwingend was bedeuten, da die Register nicht gelöscht werden, kann es auch nur ein einziger uralter Fehler sein. Um es beurteilen man muss man die Register löschen und warten, ob erneut ein Fehler auftritt.


    (Bei mir war bei einem Device, natürlich der berüchtigten ASM PCI-Bridge ;D, UncorrErr+ drin gestanden. Nach dem Löschen ist der aber bislang nicht wieder gekommen. Daher wird das wohl von der Initialisierung her kommen und unkritisch sein.)


    Hier ist das alles noch mal ganz schön erklärt: billauer.co.il...pcie-tlp-dllp-retransmit-data-link-layer-error

    Mit ECAP_AER hat es bei mir nicht immer funktioniert, CAP_EXP ging aber und sollte reichen zu beurteilen wie häufig Fehler auftreten. Man muss das Skript entsprechend anpassen.

    Die interessanten Devices sind 02:00.0 (DD) und 00:13.1 (Bus: primary=00, secondary=02).

    Dann sollte man noch die Netzwerkkarte im Auge behalten (01:00.0 00:13.0). Evtl. das auch noch mal mit der Intel-NIC durchführen um den Slot zu überprüfen.

    Wenn man dabei die Fehler protokolliert, sollte man am Ende eigentlich wissen ob die Ursache am PCIe-Link liegt und an welchem.


    Gruss
    SHF


    The post was edited 1 time, last by SHF ().


  • Thanks for the link, it looks like a very useful resource.


    Regards,

    Richard

  • Bei kls sind korrigierbare Fehler aufgetreten:

    DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-

    Das kommt hier bereits unmittelbar beim Start von VDR, ohne dass sonst ein Problem aufgetreten wäre.


    Was ich noch gesehen habe: beim NIC ist 'MaxReadReq 4096', bei ddbridge 'MaxReadReq 512'.

    Ich würde letzteres auch gerne mal auf 4096 setzen, das klappt aber nicht (siehe hier).

  • Bei der Suche nach Möglichkeiten, MaxReadReq zu verändern, bin ich auf die "Firmware Test Suite" gestoßen.

    Die Eingabe von 'fwts maxreadreq -' liefert:

    Seltsam ist, dass es meint, MaxreadReq wäre 128, dabei ist es doch angeblich 512:

    Code
    1. #> lspci -s 02:00.0 -vvv | grep MaxReadReq
    2. MaxPayload 128 bytes, MaxReadReq 512 bytes
  • Hi,

    MaxReadReq for 0000:00:02.0 is low (128). ist die CPU/GPU


    lspci -s 02:00.0 -vvv | grep MaxReadReq ist die DD


    sieht bei mir genau so aus.


    CU

    9000h

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

  • Was sagt denn nft und DD dazu?

    Mfg Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de

  • Hi,

    Sorry genau, den meinte ich. Evtl weiß er ja eine Lösung.

    Mfg Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de

  • Was ich noch gesehen habe: beim NIC ist 'MaxReadReq 4096', bei ddbridge 'MaxReadReq 512'.

    Ich würde letzteres auch gerne mal auf 4096 setzen, das klappt aber nicht (siehe hier).

    Das klappt bei mir leider auch nicht, wie ich inzwischen festgestellt habe.


    "Firmware Test Suite" werde ich mir mal ansehen.


    Das kommt hier bereits unmittelbar beim Start von VDR, ohne dass sonst ein Problem aufgetreten wäre.

    Die Frage ist, kommt es wieder, wenn man es mit setpci -d xxxx:xxxx CAP_EXP+0xa.w=0x000f löscht.

    Das Löschen klappt bei meiner PCI-Bindge (s.o.), das habe ich probiert.


    Wenn das Bit nach dem löschen unmittelbar wieder gesetzt wird, ist irgendwas mit der Verbindung faul und das Hardware nah.

    In dem Fall braucht man sich mit den Timing-Geschichten garnicht erst beschäftigen.

    Gruss
    SHF


  • -d wäre Hersteller:DeviceID. (liefert lspci -n)


    Du müsstest "-s" nehmen, wenn du die Busadresse verwendest.


    Die Busadresse wirkt auf die Karte in dem bestimmten Slot, Hersteller:DeviceID auf alle passenden Geräte egal in welchem Slot.

    Ist Geschmackssache, was man verwendet, je nach dem, was praktischer ist.

    Gruss
    SHF


  • 'setpci -s 02:00 CAP_EXP+0xa.w=0x000f' bei laufendem VDR -> CorrErr- und bleibt auch so.

    VDR-Abbruch -> es bleibt CorrErr-

    VDR-Neustart (ohne Treiber Neu-Laden) -> CorrErr+


    Beim Start von VDR (Öffnen der Devices?) passiert wohl etwas, das das Flag setzt.

    Aber wenn man es zurücksetzt, dann bleibt es zurückgesetzt.


    Starte ich den rsync, geht es nach kurzer Zeit auf CorrErr+ und einige Sekunden danach kommen die I2C-Fehler.

    UncorrErr bleibt aber die ganze Zeit auf '-'.

  • Beim Start von VDR (Öffnen der Devices?) passiert wohl etwas, das das Flag setzt.

    Beim reinen öffnen des Devices hätte ich das jetzt nicht erwartet. Da sollte die Firmware der Karte die ganze Zeit laufen.

    Eher beim laden des Treibers, das könnte mit einem Firmware-Rest der Karte verbunden sein.


    Aber wenn man es zurücksetzt, dann bleibt es zurückgesetzt.


    Starte ich den rsync, geht es nach kurzer Zeit auf CorrErr+ und einige Sekunden danach kommen die I2C-Fehler.

    Das deckt sich mit den anderen Beobachtungen.


    UncorrErr bleibt aber die ganze Zeit auf '-'.

    Dieser UncorrErr wird von der Karte gesetzt wird.

    Wenn die Firmware abgestürzt, oder der Link zusammengebrochen ist, kann es sein, dass man den schon nicht mehr auslesen kann.


    Eventuell geben da die Werte von der Gegenstelle (00:13.1) mehr Aufschluss.

    Wenn der Link unzuverlässig ist, würde ich da auch Fehler erwarten.

    Da auch mehr Daten Richtung Computer laufen, sollte "CorrErr" da eigentlich sogar früher kommen.


    Im Fehlerzustand sollte man auch mal schauen, ob es sonst noch Fehler auf dem PCIe-Bus gibt.

    lspci -vv | grep DevSta:

    Wenn es da noch mehr Fehler gibt, liegt es wohl am Mainboard.

    Wenn es nur den einen Link, mit der DD-Cine, betrifft, würde ich auf diese tippen. Die Netzwerkkarte läuft in dem Slot ja.



    BZW.:

    Ist der Stromstecker eigentlich an der Cine angeschlossen?

    Wenn nicht unbedingt mal versuchen mit, auch wenn die an einem Multiswitch hängt.

    Gruss
    SHF


  • Eventuell geben da die Werte von der Gegenstelle (00:13.1) mehr Aufschluss.


    Wenn der Link unzuverlässig ist, würde ich da auch Fehler erwarten.

    Wenn ich den Rechner neu starte hat die Gegenstelle (Treiber geladen) bereits CorrErr+, die ddbridge aber noch nicht:

    Nach dem Start von VDR hat dann auch die ddbridge CorrErr+, es läuft aber alles störungsfrei:

    Code
    1. 02:00.0 Multimedia controller: Digital Devices GmbH Cine V7
    2. DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-

    Lösche ich (bei laufendem VDR) die CorrErr+ Flags und starte dann den rsync, kommt es bei 00:13.1 zu CorrErr+ und 02:00.0 lässt sich gar nicht mehr abfragen.

    Im Fehlerzustand sollte man auch mal schauen, ob es sonst noch Fehler auf dem PCIe-Bus gibt.


    lspci -vv | grep DevSta:

    Wenn es da noch mehr Fehler gibt, liegt es wohl am Mainboard.

    Wenn es nur den einen Link, mit der DD-Cine, betrifft, würde ich auf diese tippen. Die Netzwerkkarte läuft in dem Slot ja.

    CorrErr+ tritt nur bei 02:00.0 und 00:13.1 (also der ddbridge und ihrer Gegenstation) auf.

    Ist der Stromstecker eigentlich an der Cine angeschlossen?

    Wenn nicht unbedingt mal versuchen mit, auch wenn die an einem Multiswitch hängt.

    War er nicht, der Fehler tritt aber auch bei angeschlossenem Stecker auf (gerade verifiziert).



    Da der NIC ein MaxreadReq von 4096 hat, die ddbridge aber nur 512:

    Code
    1. 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
    2. MaxPayload 128 bytes, MaxReadReq 4096 bytes
    3. 02:00.0 Multimedia controller: Digital Devices GmbH Cine V7
    4. MaxPayload 128 bytes, MaxReadReq 512 bytes

    könnte ich mir durchaus vorstellen, dass, wenn sehr starker Netzwerk-Traffic aufkommt, der Datenaustausch zwischen ddbridge und der Gegenstelle nicht mehr hinterherkommt. Daher wäre es sehr interessant, hier mal andere Werte testen zu können. Ich weiß nur leider nicht, wie ich die einstellen kann, denn mit setpci klappt es nicht (siehe hier).