A lspci -vvvsaída mostra sinalizadores como CorrErre UnCorrErr.
Gostaria de saber se esses sinalizadores podem indicar a integridade do dispositivo e se mudam com o tempo.
Um exemplo de saída é relatado abaixo.
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
Responder1
O link de outra postagem deste tópico "cirrascale.com/blog/index.php/pci-debugging-101/" não funciona mais em 2019. Porém encontrei o artigo arquivado em:
https://intrepid.warped.com/~scotte/OldBlogEntries/web/index-5.html
Aqui está um trecho do artigo vinculado:
especificar o dispositivo específico (desta vez “0000:02:00.0“) nos fornecerá detalhes.
# lspci -s 0000:02:00.0 -vvvDando a saída:
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 nos registros de status do dispositivo (“DevSta“) que o dispositivo apresentou algum tipo de erro corrigível (“CorrErr+“).
Como o erro era um erro corrigível (“CorrErr”), a parte interessante da saída AER é o status do erro corrigível (“CESta”). Nenhum dos bits é definido, exceto o bit de erro não fatal (“NoNFatalErr+“). Pelo nome disso (é um erro, mas não fatal... e foi corrigível!), isso não parece nada com que realmente se preocupar. Verificar se o erro está mascarado ou não (“ CEMsk “) mostra que o fornecedor do dispositivo optou por mascarar esse erro (“ NonFatalErr + “), então eles não acharam que era algo que deveria ser enganado na cadeia de dispositivos PCIe e tratado também . Na verdade, o PCI-SIG define erros não fatais corrigíveis como erros de “aviso” e observe que isso deve ser usado como uma indicação de um problema de software, não como um indicativo de um problema com a integridade ou funcionalidade do barramento PCIe.
Como provavelmente é óbvio, geralmente não há muita necessidade de observar dispositivos PCIe incorporados em uma placa-mãe comum, mas as etapas para descobrir onde um determinado dispositivo reside em um barramento PCIe e como ele está se comportando são as mesmas para quase todos os dispositivos. dispositivo. Um caso mais comum hoje em dia, como mencionei anteriormente, é ajudar clientes e parceiros a seguirem esses mesmos passos para produtos como o nosso GB5400.
Responder2
Não, rastrear erros corrigíveis mascarados geralmente só faz sentido se estiver impactando materialmente o desempenho dos dispositivos PCIe.