From: John.C.Harrison@Intel.com
To: Intel-Xe@Lists.FreeDesktop.Org
Cc: John Harrison <John.C.Harrison@Intel.com>
Subject: [PATCH v4 0/7] drm/xe/guc: Improve quality and robustness of GuC log dumping
Date: Mon, 10 Jun 2024 18:20:21 -0700 [thread overview]
Message-ID: <20240611012028.2305024-1-John.C.Harrison@Intel.com> (raw)
From: John Harrison <John.C.Harrison@Intel.com>
drm/xe/guc: Improve GuC log dumping and add dump on CT failures
There is a debug mechanism for dumping the GuC log as an ASCII hex
stream via dmesg. This is extremely useful for situations where it is
not possibe to query the log from debugfs (self tests, bugs that cause
the driver to fail to load, system hangs, etc.). However, dumping via
dmesg is not the most reliable. The dmesg buffer is limited in size,
can be rate limited and a simple hex stream is hard to parse by tools.
So add extra information to the dump to make it more robust and
parsable. This includes adding start and end tags to delimit the dump,
using longer lines to reduce the per line overhead, adding a rolling
count to check for missing lines and interleaved concurrent dumps and
adding other important information such as the GuC version number and
timestamp offset.
There are various internal error states that the CTB code can check
for. These should never happen but when they do (driver bug, firmware
bug or even hardware bug), they can be a nightmare to debug. So add in
a capture of the GuC log and CT state at the point of error and
subsequent dump from a worker thread.
Note that the ultimate aim is to add the GuC log to the devcoredump
capture. And then to provide a mechanism for generating a devcoredump
at an arbitrary point (such as dead CTB or failed selftest) and
dumping that to dmesg. Unfortunately, there are still issues with
doing that. But this is a good first step along the way.
v2: Remove pm get/put as unnecessary (review feedback from Matthew B).
v3: Add firmware filename and 'wanted' version number.
v4: Use DRM level line printer wrapper from Michal W. Add 'dead CTB'
dump support. Lots of restructuring of capture vs dump for both GuC
log and CTB capture for both the dead CTB dump and for future
inclusion in devcoredump.
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
John Harrison (6):
drm/xe/guc: Remove spurious line feed in debug print
drm/xe/guc: Copy GuC log prior to dumping
drm/xe/guc: Use a two stage dump for GuC logs and add more info
drm/xe/guc: Add a helper function for dumping GuC log to dmesg
drm/xe/guc: Dead CT helper
drm/xe/guc: Dump entire CTB on errors
Michal Wajdeczko (1):
drm/print: Introduce drm_line_printer
drivers/gpu/drm/drm_print.c | 14 +
.../drm/xe/abi/guc_communication_ctb_abi.h | 1 +
drivers/gpu/drm/xe/regs/xe_guc_regs.h | 1 +
drivers/gpu/drm/xe/xe_devcoredump.c | 2 +-
drivers/gpu/drm/xe/xe_guc_ct.c | 356 ++++++++++++++----
drivers/gpu/drm/xe/xe_guc_ct.h | 9 +-
drivers/gpu/drm/xe/xe_guc_ct_types.h | 24 ++
drivers/gpu/drm/xe/xe_guc_debugfs.c | 2 +-
drivers/gpu/drm/xe/xe_guc_log.c | 227 ++++++++++-
drivers/gpu/drm/xe/xe_guc_log.h | 11 +-
drivers/gpu/drm/xe/xe_guc_log_types.h | 29 ++
include/drm/drm_print.h | 64 ++++
12 files changed, 637 insertions(+), 103 deletions(-)
--
2.43.2
next reply other threads:[~2024-06-11 1:20 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-11 1:20 John.C.Harrison [this message]
2024-06-11 1:20 ` [PATCH v4 1/7] drm/xe/guc: Remove spurious line feed in debug print John.C.Harrison
2024-06-11 1:20 ` [PATCH v4 2/7] drm/xe/guc: Copy GuC log prior to dumping John.C.Harrison
2024-06-11 22:30 ` Michal Wajdeczko
2024-06-12 23:36 ` John Harrison
2024-06-11 1:20 ` [PATCH v4 3/7] drm/xe/guc: Use a two stage dump for GuC logs and add more info John.C.Harrison
2024-06-11 22:49 ` Michal Wajdeczko
2024-06-12 23:52 ` John Harrison
2024-06-11 1:20 ` [PATCH v4 4/7] drm/print: Introduce drm_line_printer John.C.Harrison
2024-06-11 1:20 ` [PATCH v4 5/7] drm/xe/guc: Add a helper function for dumping GuC log to dmesg John.C.Harrison
2024-06-11 1:20 ` [PATCH v4 6/7] drm/xe/guc: Dead CT helper John.C.Harrison
2024-06-11 23:20 ` Michal Wajdeczko
2024-06-13 0:43 ` John Harrison
2024-06-11 1:20 ` [PATCH v4 7/7] drm/xe/guc: Dump entire CTB on errors John.C.Harrison
2024-06-11 1:25 ` ✓ CI.Patch_applied: success for drm/xe/guc: Improve quality and robustness of GuC log dumping (rev2) Patchwork
2024-06-11 1:25 ` ✗ CI.checkpatch: warning " Patchwork
2024-06-11 1:26 ` ✓ CI.KUnit: success " Patchwork
2024-06-11 1:38 ` ✓ CI.Build: " Patchwork
2024-06-11 1:40 ` ✗ CI.Hooks: failure " Patchwork
2024-06-11 1:41 ` ✗ CI.checksparse: warning " Patchwork
2024-06-11 2:31 ` ✗ CI.BAT: failure " Patchwork
2024-06-11 3:53 ` ✗ CI.FULL: " Patchwork
-- strict thread matches above, loose matches on Subject: below --
2024-06-10 22:56 [PATCH v4 0/7] drm/xe/guc: Improve quality and robustness of GuC log dumping John.C.Harrison
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240611012028.2305024-1-John.C.Harrison@Intel.com \
--to=john.c.harrison@intel.com \
--cc=Intel-Xe@Lists.FreeDesktop.Org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox