I2C Timeouts mit ddbridge

ras · 7. April 2019

Hi Klaus,

Further to my post #76 above, I've just rsynced about 760GB, (about 30minutes), without any problems.

Regards,

Richard

kls · 7. April 2019

ras Can you please post the result of

lspci -s 02:00.0 -vvv

(you may need to adjust the 02 to your environment).

ras · 7. April 2019

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

SHF · 8. April 2019

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 , 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.

ras · 8. April 2019

Zitat von SHF

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.

Alles anzeigen

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

Regards,

Richard

kls · 8. April 2019

Zitat von SHF

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).

kls · 8. April 2019

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:

Code

Results generated by fwts: Version V18.11.00 (2018-11-14 08:07:31).

Some of this work - Copyright (c) 1999 - 2018, Intel Corp. All rights reserved.
Some of this work - Copyright (c) 2010 - 2018, Canonical.
Some of this work - Copyright (c) 2016 - 2018, IBM.
Some of this work - Copyright (c) 2017 - 2018, ARM Ltd.

This test run on 08/04/19 at 12:33:32 on host Linux vdr3 4.12.14-lp150.12.48-default #1 SMP Tue Feb 12 14:01:48 UTC 2019
(268f014) x86_64.

Command: "fwts maxreadreq -".
Running tests: maxreadreq.

maxreadreq: Test firmware has set PCI Express MaxReadReq to a higher value on non-motherboard devices.
---------------------------------------------------------------------------------------------------------------------------
Test 1 of 1: Test firmware settings MaxReadReq for PCI Express devices.
MaxReadReq for 0000:00:02.0 is low (128).
FAILED [LOW] LowMaxReadReq: Test 1, 1 devices have low MaxReadReq settings. Firmware may have configured these too low.

ADVICE: The MaxReadRequest size is set too low and will affect performance. It will provide excellent bus sharing at the
cost of bus data transfer rates. Although not a critical issue, it may be worth considering setting the MaxReadRequest size
to 256 or 512 to increase throughput on the PCI Express bus. Some drivers (for example the Brocade Fibre Channel driver)
allow one to override the firmware settings. Where possible, this BIOS configuration setting is worth increasing it a
little more for better performance at a small reduction of bus sharing.


===========================================================================================================================
0 passed, 1 failed, 0 warning, 0 aborted, 0 skipped, 0 info only.
===========================================================================================================================


0 passed, 1 failed, 0 warning, 0 aborted, 0 skipped, 0 info only.

Test Failure Summary
===========================================================================================================================

Critical failures: NONE

High failures: NONE

Medium failures: NONE

Low failures: 1
 maxreadreq: 1 devices have low MaxReadReq settings. Firmware may have configured these too low.

Other failures: NONE

Test           |Pass |Fail |Abort|Warn |Skip |Info |
---------------+-----+-----+-----+-----+-----+-----+
maxreadreq     |     |    1|     |     |     |     |
---------------+-----+-----+-----+-----+-----+-----+
Total:         |    0|    1|    0|    0|    0|    0|
---------------+-----+-----+-----+-----+-----+-----+

Alles anzeigen

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

Code

#> lspci -s 02:00.0 -vvv | grep MaxReadReq
MaxPayload 128 bytes, MaxReadReq 512 bytes

9000H · 8. April 2019

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

SurfaceCleanerZ · 8. April 2019

Was sagt denn nft und DD dazu?

Mfg Stefan

kls · 8. April 2019

Zitat von 9000H

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

Sorry, da hatte ich wohl nur auf die '2' geschaut... ;.-)

kls · 8. April 2019

Zitat von SurfaceCleanerZ

Was sagt denn nft und DD dazu?

Wer oder was ist 'nft'?

Ich habe DD jetzt mal auf diesen Thread aufmerksam gemacht.

Argus · 8. April 2019

Zitat von kls

Wer oder was ist 'nft'?

er meint wohl nst --> https://www.vdr-portal.de/foru…user-post-list/26091-nst/

SurfaceCleanerZ · 8. April 2019

Hi,

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

Mfg Stefan

SHF · 8. April 2019

Zitat von kls

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.

Zitat von kls

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.

kls · 8. April 2019

Ich nehme mal an, dass ich für xxxx:xxxx 02:00.0 einsetzen muss, aber:

#> setpci -d 02:00.0 CAP_EXP+0xa.w=0x000f

setpci: Unable to parse filter -d Invalid device ID.

SHF · 8. April 2019

-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.

kls · 8. April 2019

'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 '-'.

SHF · 8. April 2019

Zitat von kls

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.

Zitat von kls

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.

Zitat von kls

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.

kls · 9. April 2019

Zitat von 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:

Code

root@vdr3:/home/kls > lspci -vvv 2>/dev/null | grep -e CorrErr -e '^0'
00:00.0 Host bridge: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series Host Bridge (rev 0b)
00:02.0 VGA compatible controller: Intel Corporation Device 5a85 (rev 0b) (prog-if 00 [VGA controller])
                DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
00:0e.0 Audio device: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series Audio Cluster (rev 0b)
                DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
00:0f.0 Communication controller: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series Trusted Execution Engine (rev 0b)
00:12.0 SATA controller: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series SATA AHCI Controller (rev 0b) (prog-if 01 [AHCI 1.0])
00:13.0 PCI bridge: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series PCI Express Port A #1 (rev fb) (prog-if 00 [Normal decode])
                DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
00:13.1 PCI bridge: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series PCI Express Port A #2 (rev fb) (prog-if 00 [Normal decode])
                DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
00:13.2 PCI bridge: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series PCI Express Port A #3 (rev fb) (prog-if 00 [Normal decode])
                DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
00:13.3 PCI bridge: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series PCI Express Port A #4 (rev fb) (prog-if 00 [Normal decode])
                DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
00:15.0 USB controller: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series USB xHCI (rev 0b) (prog-if 30 [XHCI])
00:1f.0 ISA bridge: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series Low Pin Count Interface (rev 0b)
00:1f.1 SMBus: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series SMBus Controller (rev 0b)
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
                DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
02:00.0 Multimedia controller: Digital Devices GmbH Cine V7
                DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-

Alles anzeigen

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

Code

02:00.0 Multimedia controller: Digital Devices GmbH Cine V7
                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.

Zitat von SHF

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.

Zitat von SHF

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

01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
                        MaxPayload 128 bytes, MaxReadReq 4096 bytes
02:00.0 Multimedia controller: Digital Devices GmbH Cine V7
                        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).

jrie · 9. April 2019

Falls der NIC auf andere Werte einstellen besser reagiert, könntest du ja mal den Wert vom NIC senken (als Experiment).

I2C Timeouts mit ddbridge

Jetzt mitmachen!

Teilen