diff options
| author | Michal Wajdeczko <michal.wajdeczko@intel.com> | 2026-09-04 19:05:30 +0200 |
|---|---|---|
| committer | Michal Wajdeczko <michal.wajdeczko@intel.com> | 2026-09-11 19:52:14 +0200 |
| commit | 7dbd24e9d5311b6afdbdd875dd247ab5ff54edca (patch) | |
| tree | a3804edc30fc406affef46c6e4bc875d0a43a67f /tools/perf/scripts/python/bin/stackcollapse-record | |
| parent | a158eba2fb0d82b7a11f316c6b4065d5861ba0dd (diff) | |
| download | linux-7dbd24e9d5311b6afdbdd875dd247ab5ff54edca.tar.gz linux-7dbd24e9d5311b6afdbdd875dd247ab5ff54edca.zip | |
drm/xe/log: Relax location ID recognition
It turned out that during early probe phase, VFs use detached from
the xe_device, temporary xe_gt objects, which when used as location
in xe_log() macros, will be treated by the dmesg decoration code as
bogus, possibly triggering a WARN, and the output will look like:
[drm] *ERROR* SIGID=104 (-ETIMEDOUT) LOC3.0? GUC: MMIO request ...
instead of expected:
[drm] *ERROR* SIGID=104 (-ETIMEDOUT) Tile0: GT0: GUC: MMIO request ...
Relax the tile/GT id validation and instead of looking for the real
objects, only check if encoded id is within the range of possible
tiles or GTs on the current xe device, using data from the device
descriptor rather then the object list.
Fixes: 1151b9f6f465 ("drm/xe/log: Add component/location decorations to dmesg")
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patch.msgid.link/20260904170531.516-7-michal.wajdeczko@intel.com
Diffstat (limited to 'tools/perf/scripts/python/bin/stackcollapse-record')
0 files changed, 0 insertions, 0 deletions
