Xe 裝置 Coredump

Xe 使用 dev_coredump 基礎設施以標準化方式暴露崩潰錯誤。一旦發生崩潰，devcoredump 會在 /sys/class/devcoredump/devcd<m>/ 下暴露一個臨時節點。相同的節點也可以在 /sys/class/drm/card<n>/device/devcoredump/ 中訪問。failing_device 符號連結指向崩潰並建立 coredump 的裝置。

xe 在建立裝置 coredump 時觀察到以下特性

掛起時的快照:

“data” 檔案包含掛起發生時硬體和驅動程式狀態的快照。由於驅動程式從復位/崩潰中恢復，它可能與使用者空間讀取檔案時的系統狀態不對應。

Coredump 釋放:

生成 coredump 後，它會保留在核心記憶體中，直到使用者空間寫入任何內容來釋放它，或者在內部計時器過期後釋放。確切的超時時間可能會有所不同，不應依賴。釋放 coredump 的示例

$ > /sys/class/drm/card0/device/devcoredump/data

僅第一次失敗:

一般來說，第一次掛起是最關鍵的，因為隨後的掛起可能是初始掛起的後果。因此，僅對第一次失敗拍攝快照。在使用者空間或核心釋放 devcoredump 之前，所有後續掛起都不會覆蓋快照或建立新快照。Devcoredump 有一個延遲工作佇列，最終將刪除檔案節點並釋放所有轉儲資訊。

內部 API

void xe_devcoredump(struct xe_exec_queue *q, struct xe_sched_job *job, const char *fmt, ...)

獲取所需的快照並初始化 coredump 裝置。

引數

struct xe_exec_queue *q

發生問題的有缺陷的 xe_exec_queue。

struct xe_sched_job *job

發生問題的有缺陷的 xe_sched_job。

const char *fmt

Printf 格式 + 用於描述核心轉儲原因的引數

...

可變引數

描述

此函式應在序列化的 gt_reset 中在崩潰時呼叫。如果我們仍然可以使用核心轉儲裝置以及“第一個”快照的資訊，則會跳過它。

void xe_print_blob_ascii85(struct drm_printer *p, const char *prefix, char suffix, const void *blob, size_t offset, size_t size)

以 ASCII85 格式將 BLOB 列印到一些有用的位置

引數

struct drm_printer *p

要輸出到的印表機物件

const char *prefix

新增到輸出字串的可選字首

char suffix

新增到末尾的可選後綴。 0 停用它，並且不新增到輸出中，這在使用多次呼叫將資料轉儲到 p 時非常有用

const void *blob

要轉儲的大型二進位制物件

size_t offset

從 BLOB 前面跳過的位元組偏移量，必須是 sizeof(u32) 的倍數

size_t size

BLOB 的大小（以位元組為單位），必須是 sizeof(u32) 的倍數

描述

輸出被拆分為對 drm_puts() 的多次呼叫，因為某些列印目標（例如 dmesg）無法處理任意長的行。這些目標可能會新增換行符，就像 dmesg 一樣：每次呼叫 drm_puts() 都會建立單獨的一行。

還有一個排程程式讓步呼叫，以防止在透過序列埠列印到 dmesg 等慢速目標時觸發“任務已卡住 120 秒”核心掛起檢查功能。