El lspci -vvvresultado muestra indicadores como CorrErry UnCorrErr.
Me pregunto si estas banderas pueden indicar el estado del dispositivo y si cambian con el tiempo.
A continuación se presenta un resultado de muestra.
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
Respuesta1
El enlace de otra publicación de este hilo "cirrascale.com/blog/index.php/pci-debugging-101/" ya no funciona en 2019. Sin embargo, encontré el artículo archivado en:
https://intrepid.warped.com/~scotte/OldBlogEntries/web/index-5.html
Aquí hay un extracto del artículo vinculado:
al especificar el dispositivo en particular (esta vez “0000: 02: 00. 0”) obtendremos detalles.
# lspci -s 0000:02:00.0 -vvvDando la salida:
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+Podemos ver en los registros de estado del dispositivo (“DevSta”) que el dispositivo ha experimentado algún tipo de error corregible (“CorErr+”).
Dado que el error era un error corregible (“CorErr”), la parte interesante de la salida de AER es el estado del error corregible (“CESta”). Ninguno de los bits está configurado excepto el bit de error no fatal (“ NoNFatalErr+ “). Por su nombre (es un error, pero no fatal... ¡y se pudo corregir!), esto no parece nada de qué preocuparse. Verificar si el error está enmascarado o no (" CEMsk ") muestra que el proveedor del dispositivo eligió enmascarar ese error (" NonFatalErr+ "), por lo que no pensaron que fuera algo que debiera engañarse en la cadena de dispositivos PCIe y manejarse. . En verdad, PCI-SIG define los errores corregibles no fatales como errores de "aviso", y tenga en cuenta que deben usarse como una indicación de un problema de software, no como indicativos de un problema con la integridad o funcionalidad del bus PCIe.
Como probablemente sea obvio, generalmente no es necesario examinar los dispositivos PCIe que están integrados en una placa base básica, pero los pasos para determinar dónde se encuentra un dispositivo en particular en un bus PCIe y cómo se comporta son los mismos para la mayoría. dispositivo. Un caso más común hoy en día, como mencioné anteriormente, es ayudar a clientes y socios a seguir estos mismos pasos para productos como nuestro GB5400.
Respuesta2
No, rastrear errores corregibles enmascarados generalmente solo tiene sentido si afectan materialmente el rendimiento de los dispositivos PCIe.