1.PCIe錯誤報告的兩種機制
1. Baseline Error Reporting:該機制是PCIe設備必需支持的一種錯誤報告機制,同時設備會定義最小的錯誤報告請求。應該是通過配置Device Control和Command寄存器做到通知其他設備產生了錯誤的一種機制。
2. Advanced Error Reporting(AER):該機制是PCIe設備用來獲取更健壯的錯誤報告信息的一種特殊機制。該機制的相關寄存器會在PCIe擴展配置空間中上報。
2.PCIe錯誤的分類
由上圖可以看出PCIe將各個層產生的錯誤大致分為兩類:Correctable和Uncorrectable。
其中又將Uncorrectable分為Fatal和Nonfatal兩種。通過分類平臺可以對Correctable甚至Uncorrectable-Nonfatal的錯誤分配低優先級的處理,或者檢測錯誤頻率等處理;對于Uncorrectable-Fatal的錯誤可能直接對系統復位處理。
CorrectableErrors:是指可糾正的錯誤,在硬件不經過軟件的干預可以通過自身的邏輯糾正的錯誤。對于一些可糾正的錯誤如果處理校正的設備不處理的話需要將錯誤報告成Uncorrectable Errors。
UncorrectableErrors:不可糾正的錯誤,這類錯誤會影響接口的功能,這類錯誤在協議中沒有明確的機制可以糾正。對于PCIe具備更健壯的錯誤處理機制的設備來說,會進一步區分該錯誤為:Fatal和Non-Fatal。
FatalError:這類錯誤導致鏈路和硬件異常只有通過復位操作實現恢復。
Non-Fatal:這類錯誤可能會導致特定的傳輸變得不可靠,但是鏈路和硬件的其他功能不受影響。設備驅動軟件提供恢復機制,并不會影響到鏈路和其他設備的運行。
3.錯誤信號轉發和通知
PCIe提供了三種方式轉發通知錯誤:
1.通過回復完成狀態CompletionStatus
2. 通過錯誤消息 errorMessages
3.1 Completion Status:
針對Non-Posted請求,一些錯誤可以通過completion status的方式通知系統或其他設備,這種方式的通知,使上層協議或者軟件有機會可以判斷狀態做相應的補救處理。
3.2 Error Message:
根據錯誤的嚴重程度,不同類型的Error Message會被發送給RC。
對于PCIe1.0和1.0a之前的協議一般規定:correctable error發送ERR_COR,non-fatal errors發送ERR_NONFATAL,fatal error發送ERR_FATAL。
隨后版本的協議支持Role-Based Error Reporting,可以進一步通過檢測設備的身份和AER相關配置將non-fatal error以ERR_NONFATAL或ERR_COR的方式發出去,甚至不發通知。因為在一些平臺下發送ERR_NONFATAL可能會阻止其他設備的恢復操作或者決定錯誤的最終處理,由于不是最合適決定錯誤最終處理的設備,該設備可以通過配置AER來將錯誤已ERR_COR的形式通知其他設備,如果是最合適的設備則會以ERR_NONFATAL消息的方式通知其他設備。
對于ERR_NONFATAL,如果軟件想避免后續接受設備的錯誤檢測,可以直接配置AER將該錯誤升級為ERR_FATAL,后續的設備總是會以ERR_FATAL的方式轉發下去,無論后續設備是哪種身份。
3.2.1錯誤消息嚴重性可編程
對于不同的設備對致命和非致命的界定不同,AER提供了錯誤消息可編程的機制。AER以協議Error list中判定的消息結果作為默認發送的方式,但是也可通過編程AER的一些寄存器發送更高級的錯誤消息。
3.2.2錯誤消息屏蔽
只有當Device Control 寄存器的Reporting Enable fields或PCI Command寄存器的SERR# Enable位置1的情況下設備才能轉發消息,此外如果配置了AER的設備可以通過Uncorrectable Error Mask寄存器和Correctable Error Mask寄存器對不同的error進行屏蔽操作。
3.2.3 錯誤消息污染
如果錯誤沒有得到隔離導致后續的錯誤覆蓋最根本的錯誤這種情況就是錯誤污染,比如一個TLP在數據鏈路層出錯的話就不再上傳到事務層,而是丟棄這個TLP,上報錯誤消息。如果產生錯誤污染就很難定位到根本的錯誤消息是從哪里產生的。對于產生自同一源的錯誤協議規定了錯誤的優先級,越底層的錯誤其優先級越高。
· 不可更正的內部錯誤(Uncorrectable Internal Error)
· 接收端Buffer溢出
· 流量控制協議錯誤
· ECRC校檢失敗
· 異常的TLP(Malformed TLP)
· AtomicOp Egress Blocked
· TLP包頭異常(TLP Prefix Blocked)
· 訪問控制服務(Access Control Services,ACS)異常
· MC(Multi-cast) Blocked TLP
· 不支持的請求(Unsupported Request,UR),Completer Abort(CA)或者不對應的返回包(Unexpected Completion)
· 接收到損壞的數據包(Poisoned Packet)
3.2.4 AdvisoryNon-FatalError(警告性的非致命錯誤)
在一些情況下如果檢測到ERR_NONFATAL錯誤的設備并不是最終決定錯誤處理的設備,設備如果配有AER則發送ERR_COR提醒軟件,若果沒有配置AER則不發送消息通知軟件。PCIe規定以下幾種情況為警告性的非致命錯誤:
1.CompleterSending a CompletionwithUR/CA Status
2.IntermediateReceive
3.UltimatePCIExpressReceiverofaPoisonedTLP
4.Requesterwith completion timeout
5.Receiver of an unexpected completion
3.3錯誤轉發(Datapoisoning)
一旦出現這種情況TLP的EP位被置1,TLP整個路由流程中的接收者都將報告接收到這個poison的TLP,從而能追蹤出現問題的位置。
4.錯誤日志記錄
如果設備不支持AER,只有通過查看Device Status寄存器中是否檢測到錯誤,如果支持AER則對應的Uncorrectable Error Status寄存器和Correctable Error Status寄存器會記錄相應狀態。對于明確的事務層的錯誤AER的Header Log寄存器會記錄第一個uncorrectable error TLP的頭。
4.1錯誤源溯源
錯誤消息中包含Requester ID如下圖:
系統軟件可以根據RootPort或者RootComplexEventCollector的AER寄存器的內容獲取有效的信息
4.2多條錯誤的處理(支持AER設備)
對于一個設備如果同時收到多條錯誤,其AER狀態寄存器的位會置上,直到軟件清理或者復位清除。即使AER的多個狀態位被置起,但是First Error Pointer寄存器和Header Log寄存器中記錄的信息還是第一個錯誤的信息。即使這樣還是應該及時的處理First Error Pointer寄存器和Header Log寄存器的信息,防止后續錯誤增加系統的風險。
5. 流程中涉及到的寄存器介紹
5.1 PCIe標準配置空間的Command Register和Status Register
5.2PCIE Capabilities寄存器的Device Control和Status寄存器
5.3AER寄存器介紹
5.3.1Uncorrectable/correctableErrorStatus/mask/severityRegister
Uncorrectable和correctable的status mask severity寄存器類似,值得注意的是correctable系列的寄存器有個Advisory Non-Fatal Error Status(mask/severity),處理上文中提及的警告性的非致命錯誤。對于Uncorrectable的錯誤有Severity寄存器來配置對應錯誤的嚴重性,而Correctable的錯誤并沒有對應的Severity寄存器。
Status:當產生相應的錯誤時,Status寄存器的相應位會被置1;
Mask:當對應錯誤的mask位置1時,將不再上報錯誤消息,雖然mask被置1,但是如果有錯誤產生status相應位仍會置1;
Severity:根據設備的不同要求,可以將uncorrectable error的嚴重程度配置,1則表示fatal error;
5.3.2AdvancedErrorCapabilitiesandControlRegister
First Error Pointer:表示status中報告的第一個錯誤(對應的status的bit位)
5.3.3HeaderLogRegister
Header Log Register:記錄了第一個錯誤TLP的Header內容。
6.錯誤消息上報和記錄流程
7.Errormessage路由過程中的寄存器控制流程
8.總結
Advanced Error Reporting(AER)機制提供了更健壯和豐富的錯誤消息機制,比傳統的PCIe Baseline Error Reporting機制提供了更多的錯誤處理。AER機制讓錯誤信號更加豐富,讓Fw開發人員可以根據不同的場景對錯誤做出不同的響應。
責任編輯人:CC
-
PCIe
+關注
關注
15文章
1260瀏覽量
83186
原文標題:談談PCIe錯誤報告機制
文章出處:【微信號:dputech,微信公眾號:DapuStor】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論