PCIe Chapter 12：錯誤證據、回報與隔離

先看本章的角色與路徑

AER（Advanced Error Reporting，進階錯誤回報）提供錯誤狀態、回報控制及相關紀錄。本章先走正常的錯誤回報路徑，再解釋遮罩與 DPC 隔離如何改變軟體看到的資訊。

DPC

Downstream Port Containment，下游連接埠錯誤隔離

前情提要：Chapter 5 的交易識別用來解讀有效的 Header Log；Chapter 7 的通知概念用來理解 Root 端如何把事件交給軟體。

規格路線：Figure 6-1 的分類 → Status／Mask／Severity → Figure 6-3 的回報路徑 → Root 紀錄 → 保存與清除 → DPC 分支。

DPC

Downstream Port Containment，下游連接埠錯誤隔離

先建立從 Function 到 Root 的證據關係

Correctable Error 可由協定恢復，但可能影響效能。Uncorrectable Error 影響功能，並依嚴重程度分為 Non-Fatal／Fatal；Non-Fatal 不能解成工作已成功，Fatal 也不是某顆晶片損壞的直接診斷。AER 提供比基本錯誤回報更細的狀態、遮罩、嚴重程度與 Log；沒有 AER 不等於完全沒有錯誤回報。

依序查看來源 Function 的 Status、偵測當時的 Mask／Severity／Device Control、有效 Header Log，再到 Root Error Status／Source ID 比對。若可能有隔離，另查 DPC Status。不同時間的設定不能自動套回事發時刻。依據：§6.2.1–§6.2.4（pp.669–679）、Figure 6-1（p.670）。

兩個 Status bit，只有一個未被遮罩

在 03:00.0 走訪 Extended Capability 清單，依 Figure 7-154 找到 AER ID=0x0001。本例 base=0x100，Version=2、Next=0；不能把 Base 6.0 的所有 Flit 欄位都當成這個 Function 的能力。假設先前紀錄已清、設定自事件前未變，沿途轉送條件已啟用。

0x00044000 & ~0x00040000 = 0x00004000，本例只有 Timeout 未遮罩。Masked error 仍能設定 Status，但不為該次錯誤送出 Error Message，也不寫入 Header Log、TLP Prefix Log 或 FEP。Fatal Severity 不會越過 Mask。本例 Timeout 依 Severity 與 Device Control 產生 ERR_NONFATAL；這些值是設定後快照，不是預設值。

完整回報還有沿途 Bridge、Root primary interface 與中斷條件。依 Figure 6-3 查整條路徑；Unsupported Request／Advisory Non-Fatal 另有規則，不能普遍套用本例運算。

先確認 Log 有效，再解碼交易

FEP=14 且 Status bit 14=1，因此 FEP 有效。Completion Timeout Header Log Capable bit 12=1 才支持本例記下超時 Request；Multiple Header Recording bits 9、10=0，沒有 Flit／Prefix。本例用四 DWORD Log 容量，並只解讀三 DWORD Header。

Request 範圍為 0x40001000–0x400010FF，共 256 bytes；記錄的是未如期完成的 Request，不是超時的 Completion。Figure 7-161 的 DWORD 排列把 Header byte 0 放在 bits 31:24，不能再把上表反轉一次。Flit Log 須改查 Logged TLP was Flit Mode、Header Log Size、Logged TLP Size 與 Type／OHC。

OHC

Orthogonal Header Content，Flit模式的擴充標頭內容

Log 只能定位交易與等待結果，不能單獨指定 Endpoint、Completer、Link 或平台誰造成問題。它也不能分配給已 Mask、沒有本次 Log 的 Malformed TLP。

Root 的 Source ID 是第一個回報者

本例 Root 中斷向量編號為 0，且 primary interface 傳送條件已滿足。Source ID 表示回報 Timeout 的 Endpoint，不等於物理故障根因。第二個同類訊息會設 Multiple bit，但不取代第一個 Source ID。

Root Status 更新不受 Root Error Command／Root Control 控制，仍需要適用的 primary interface 傳送允許。要證明 CPU 收到中斷，還需向量與路由證據。依據：Figures 7-162–7-164／Tables 7-142–7-144（pp.1123–1127）。

清除前，先保存能互相比對的紀錄

作者建議先保存狀態、設定、FEP、有效 Log 與 Root／DPC 證據，並確認並行變化；多個 Register 的讀取不是自動原子快照。清除 FEP 指向的 Status 後，硬體可能換入下一筆 Log，所以先清再讀會破壞關聯。

啟用 Multiple Header Recording 且 FEP 有效時，規格建議依 FEP 逐筆處理，不清其他 Status；確定沒有 Header 的 masked error 有列明例外。PCI Status 與 AER Status 也不會互相連帶清除。依據：§6.2.4.2（pp.679–681，註腳 108）、§6.2.7.1（p.691）。

DPC 可能在 Root 收到原訊息之前隔離

換成另一事件：Switch Downstream Port 02:01.0 有 DPC base=0x300，不使用 RP Extensions。

Enable=10b 可因本地未遮罩 Uncorrectable Error 或收到 ERR_NONFATAL／ERR_FATAL 觸發。此例 Reason=01b，Source ID 因而有效；若 Reason=00b，不能用 Source ID 判來源。觸發訊息在 Port 被丟棄，不再向 Root 轉送。本例只開 DPC 中斷、未開 DPC ERR_COR，所以不能要求 Root 出現前例的 0x24。

清掉通知後，Link 為什麼還沒有回來？

Figure 7-300 把 DPC Trigger Status 放在 bit 0，DPC Interrupt Status 放在 bit 3。兩者都能寫入 1 清除，但作用不同：bit 3 處理中斷狀態；bit 0 維持隔離，清除後才允許 LTSSM離開 Disabled，回到 Detect 嘗試建立 Link。

LTSSM

Link Training and Status State Machine，鏈結訓練與狀態機

隔離期間又來一筆 Memory Read，誰回覆？

接著讀 §2.9.3 Transaction Layer Behavior During Downstream Port Containment。假設 Root Complex 送來一筆新的、格式合法的 Memory Read，原本應由 02:01.0 轉送到 03:00.0 的 BAR；它在 Port 已處於 DPC 時才提交給下游傳送路徑。這筆 Request 由 Port 丟棄，並由 Port 產生錯誤 Completion（交易回覆）。

BAR

Base Address Register，基底位址暫存器

為了知道回覆哪種錯誤，回到 Figure 7-299／Table 7-263：本例 DPC Control=0x000A，bit 2 的 DPC Completion Control=0，因此回覆 Completer Abort（CA，完成端中止）；若該 bit=1，才改回 Unsupported Request（UR，不支援的要求）。此 Completion 的 Completer ID 是 Downstream Port 02:01.0，因為這次由它終止 Request；前面 DPC Error Source ID 的 03:00.0 則是觸發隔離訊息的回報者。

在這個情境中收到 CA，是 Port 依 DPC 規則產生的結果，無法據此宣稱 Endpoint 已接受或執行該次讀取。若換成隔離前就已送出的 Request，且 DPC 使 Completion 無法回來，本例沒有 Root Port Extensions 的代回覆機制，Requester 仍可能遇到 Completion Timeout。新的 Request 如何被終止，與舊 Request 是否已完成，要分別追蹤。

解除隔離後，還有哪些恢復工作？

Table 7-264 說明，清除 DPC Trigger Status 後，Port 離開 DPC，LTSSM 必須回 Detect。這只是重新嘗試訓練；接著還要觀察 Link 與 Data Link 恢復，並依 §6.6.1 遵守 Conventional Reset（一般重設）之後首次 Configuration Read 的適用時序，才能繼續恢復設定與驅動程式。等待條件連回 Chapter 9，不在這裡重複全部 Reset 流程。

解除隔離也會改變紀錄的判讀條件：DPC Trigger Status=0 後，DPC Trigger Reason 已不再有效，應使用先前保存的快照分析本次事件。規格允許在釋放要求已滿足後清除 Trigger Status，不必等所有相關錯誤 Status 都變成 0；因此，清空整片錯誤紀錄並不是恢復的必要前提。裝置如何重建工作、處理先前在途資料及恢復應用服務，則仍須裝置、驅動與平台的恢復程序。

確認證據的限制