Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: John.C.Harrison@Intel.com
To: Intel-Xe@Lists.FreeDesktop.Org
Cc: John Harrison <John.C.Harrison@Intel.com>
Subject: [RFC 0/5] drm/xe: Support capture and dump of devcoredump for general debug
Date: Fri,  8 Nov 2024 17:59:29 -0800	[thread overview]
Message-ID: <20241109015934.2203462-1-John.C.Harrison@Intel.com> (raw)

From: John Harrison <John.C.Harrison@Intel.com>

It is useful to be able to dump driver/hardware state when various
unexpected errors occur. E.g. on an internal error in the GuC
communication layer, there is a dump of the GuC state. Currently the
CT code rolls its own capture and print. However, the devcoredump
mechanism is basically doing exactly the same thing. So tweak that to
allow it to be called from arbitrary places and use it instead.

Signed-off-by: John Harrison <John.C.Harrison@Intel.com>


John Harrison (5):
  drm/xe/devcoredump: Support coredumps without jobs
  drm/xe: Trigger a devcoredump capture on a GT reset
  drm/xe: Disconnect coredump structure from xe_device structure
  drm/xe: Make coredump printing to in-memory cache optional
  drm/xe: Support devcoredump capture from dead CT handler

 drivers/gpu/drm/xe/xe_devcoredump.c       | 266 ++++++++++++++++------
 drivers/gpu/drm/xe/xe_devcoredump.h       |   9 +-
 drivers/gpu/drm/xe/xe_devcoredump_types.h |   2 +
 drivers/gpu/drm/xe/xe_gt.c                |   4 +
 drivers/gpu/drm/xe/xe_guc_ct.c            |  57 +++--
 drivers/gpu/drm/xe/xe_guc_ct_types.h      |   6 +-
 drivers/gpu/drm/xe/xe_guc_submit.c        |   2 +-
 7 files changed, 241 insertions(+), 105 deletions(-)

-- 
2.47.0


             reply	other threads:[~2024-11-09  1:59 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-09  1:59 John.C.Harrison [this message]
2024-11-09  1:59 ` [RFC 1/5] drm/xe/devcoredump: Support coredumps without jobs John.C.Harrison
2024-11-09  1:59 ` [RFC 2/5] drm/xe: Trigger a devcoredump capture on a GT reset John.C.Harrison
2024-11-09  1:59 ` [RFC 3/5] drm/xe: Disconnect coredump structure from xe_device structure John.C.Harrison
2024-11-09  1:59 ` [RFC 4/5] drm/xe: Make coredump printing to in-memory cache optional John.C.Harrison
2024-11-09  1:59 ` [RFC 5/5] drm/xe: Support devcoredump capture from dead CT handler John.C.Harrison
2024-11-09  2:05 ` ✓ CI.Patch_applied: success for drm/xe: Support capture and dump of devcoredump for general debug Patchwork
2024-11-09  2:05 ` ✗ CI.checkpatch: warning " Patchwork
2024-11-09  2:06 ` ✓ CI.KUnit: success " Patchwork
2024-11-09  2:18 ` ✓ CI.Build: " Patchwork
2024-11-09  2:20 ` ✓ CI.Hooks: " Patchwork
2024-11-09  2:22 ` ✓ CI.checksparse: " Patchwork
2024-11-09  2:39 ` ✓ CI.BAT: " Patchwork
2024-11-10  3:58 ` ✗ CI.FULL: failure " Patchwork

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=20241109015934.2203462-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