☰

Die lspci -vvv-Ausgabe CorrErr und UnCorrErr ändert sich im Laufe der Zeit

tag-icon • tag-icon command-line
Die lspci -vvv-Ausgabe CorrErr und UnCorrErr ändert sich im Laufe der Zeit

Die lspci -vvvAusgabe zeigt Flags wie CorrErrund UnCorrErr.
Ich frage mich, ob diese Flags den Zustand des Geräts anzeigen können und ob sie sich im Laufe der Zeit ändern.

Unten finden Sie eine Beispielausgabe.

    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, Cache Line Size: 64 bytes
    Interrupt: pin A routed to IRQ 19
    Region 0: Memory at f6101000 (32-bit, non-prefetchable) [size=2K]
    Region 1: Memory at f6100000 (32-bit, non-prefetchable) [size=256]
    Capabilities: [44] 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: [80] Express (v1) Endpoint, MSI 00
            DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 64ns, L1 1us
                    ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
            DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
                    RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
                    MaxPayload 128 bytes, MaxReadReq 16384 bytes
            DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
            LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 unlimited, L1 unlimited
                    ClockPM- Surprise- LLActRep- BwNot-
            LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
                    ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
            LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
    Capabilities: [94] MSI: Enable- Count=1/1 Maskable- 64bit-
            Address: fffffffc  Data: 0000

Antwort1

Der Link aus einem anderen Beitrag dieses Threads „cirrascale.com/blog/index.php/pci-debugging-101/“ funktioniert im Jahr 2019 nicht mehr. Ich habe den Artikel jedoch archiviert hier gefunden:

https://intrepid.warped.com/~scotte/OldBlogEntries/web/index-5.html

Hier ein Auszug aus dem verlinkten Artikel:

Durch Angabe des jeweiligen Geräts (diesmal „0000:02:00.0“) erhalten wir Details.

# lspci -s 0000:02:00.0 -vvv

Die Ausgabe lautet:

02:00.0 Serial Attached SCSI controller: LSI Logic / Symbios Logic SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] (rev 03)

...

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

...

CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+

CEMsk: RxErr+ BadTLP+ BadDLLP+ Rollover+ Timeout+ NonFatalErr+

Aus den Gerätestatusregistern („DevSta“) können wir ersehen, dass beim Gerät ein behebbarer Fehler („CorrErr+“) aufgetreten ist.

Da es sich bei dem Fehler um einen korrigierbaren Fehler („CorrErr“) handelte, ist der interessante Teil der AER-Ausgabe der korrigierbare Fehlerstatus („CESta“). Außer dem Bit für nicht schwerwiegende Fehler („NoNFatalErr+“) ist keines der Bits gesetzt. Der Name (es ist ein Fehler, aber kein schwerwiegender … und er war korrigierbar!) lässt vermuten, dass es sich nicht um einen wirklich besorgniserregenden Fehler handelt. Die Überprüfung, ob der Fehler maskiert ist oder nicht („CEMsk“), zeigt, dass der Gerätehersteller sich dafür entschieden hat, diesen Fehler zu maskieren („NonFatalErr+“), sodass er nicht der Meinung war, dass es sich um etwas handelte, das in der PCIe-Gerätekette ausgetrickst und behandelt werden sollte. Tatsächlich definiert die PCI-SIG korrigierbare nicht schwerwiegende Fehler als „beratende“ Fehler, und beachten Sie, dass dies als Hinweis auf ein Softwareproblem verwendet werden sollte und nicht als Hinweis auf ein Problem mit der Integrität oder Funktionalität des PCIe-Busses.

Wie wahrscheinlich offensichtlich ist, besteht normalerweise kein großer Bedarf, PCIe-Geräte zu untersuchen, die auf einem Standard-Motherboard eingebettet sind. Die Schritte, um herauszufinden, wo sich ein bestimmtes Gerät auf einem PCIe-Bus befindet und wie es sich verhält, sind jedoch für fast alle Geräte gleich. Ein heutzutage häufigerer Fall ist, wie ich bereits erwähnt habe, Kunden und Partnern dabei zu helfen, dieselben Schritte für Produkte wie unser GB5400 durchzuführen.

Antwort2

Nein, die Suche nach maskierten, korrigierbaren Fehlern ist normalerweise nur dann sinnvoll, wenn die Leistung der PCIe-Geräte erheblich beeinträchtigt wird.

http://www.cirrascale.com/blog/index.php/pci-debugging-101/

verwandte Informationen