☰

Вывод 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.

Как, вероятно, очевидно, обычно не так уж много смысла смотреть на устройства PCIe, встроенные в материнскую плату, но шаги по выяснению того, где конкретное устройство находится на шине PCIe и как оно себя ведет, одинаковы для большинства устройств. Более распространенный случай в наши дни, как я уже упоминал ранее, — это помощь клиентам и партнерам в выполнении тех же шагов для таких продуктов, как наш GB5400.

решение2

Нет, отслеживание скрытых исправимых ошибок обычно имеет смысл только в том случае, если они существенно влияют на производительность устройств PCIe.

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

Связанный контент