☰

lspci -vvv 輸出 CorrErr 和 UnCorrErr 隨時間變化

tag-icon • tag-icon command-line
lspci -vvv 輸出 CorrErr 和 UnCorrErr 隨時間變化

輸出lspci -vvv顯示諸如CorrErr和 之類的標誌UnCorrErr。
我想知道這些標誌是否可以指示設備的運作狀況以及它們是否隨著時間的推移而變化。

下面報告了範例輸出。

    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

答案1

該線程的另一篇文章“cirrascale.com/blog/index.php/pci-debugging-101/”中的連結在 2019 年不再有效。

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

以下是連結文章的摘錄：

指定特定設備（這次“0000:02:00.0”）將為我們提供詳細資訊。

# lspci -s 0000:02:00.0 -vvv

給出輸出：

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+

我們可以從裝置狀態暫存器（「 DevSta 」）中看到裝置遇到了某種可修正的錯誤（「 CorrErr+ 」）。

由於錯誤是可糾正錯誤（“ CorrErr ”），因此 AER 輸出中有趣的部分是可糾正錯誤狀態（“ CEsta ”）。除了非致命錯誤位元（“NoNFatalErr+”）之外，沒有任何位元被設定。顧名思義（這是一個錯誤，但不是致命的錯誤……而且它是可以糾正的！），這聽起來沒什麼值得擔心的。檢查錯誤是否被屏蔽（「 CEMsk 」）表示裝置供應商選擇封鎖該錯誤（「 NonFatalErr+ 」），因此他們認為不應在 PCIe 裝置鏈上欺騙並處理該錯誤。事實上，PCI-SIG 將可糾正的非致命錯誤定義為「建議」錯誤，並請注意，它應該用作軟體問題的指示，而不是指示 PCIe 總線的完整性或功能性問題。

As is probably obvious, there's not usually much call for looking at PCIe devices that are embedded on a commodity motherboard, but the steps to figuring out where a particular device lives on a PCIe bus, and how it is behaving are the same for most any裝置.正如我之前提到的，如今一個更常見的案例是幫助客戶和合作夥伴對 GB5400 等產品遵循相同的步驟。

答案2

不會，通常只有在對 PCIe 裝置的效能產生重大影響時，追蹤被封鎖的可修正錯誤才有意義。

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

相關內容