From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Stuart Summers <stuart.summers@intel.com>
Cc: intel-xe@lists.freedesktop.org
Subject: Re: [Intel-xe] [PATCH 2/2] drm/xe: Add coredump to wa_bb timeouts
Date: Wed, 4 Oct 2023 09:40:40 -0400 [thread overview]
Message-ID: <ZR1rWD6BZgDOk6+3@intel.com> (raw)
In-Reply-To: <20230926212056.40881-2-stuart.summers@intel.com>
On Tue, Sep 26, 2023 at 09:20:56PM +0000, Stuart Summers wrote:
> We're seeing some hangs during driver load on some platforms
> in CI which are hard to catch manually. As such, add the dump
> at the time of the hang.
>
> Signed-off-by: Stuart Summers <stuart.summers@intel.com>
> ---
> drivers/gpu/drm/xe/xe_gt.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/xe/xe_gt.c b/drivers/gpu/drm/xe/xe_gt.c
> index 1aa44d4f9ac1..80ea076197e5 100644
> --- a/drivers/gpu/drm/xe/xe_gt.c
> +++ b/drivers/gpu/drm/xe/xe_gt.c
> @@ -46,6 +46,7 @@
> #include "xe_vm.h"
> #include "xe_wa.h"
> #include "xe_wopcm.h"
> +#include "xe_devcoredump.h"
>
> struct xe_gt *xe_gt_alloc(struct xe_tile *tile)
> {
> @@ -187,8 +188,10 @@ static int emit_wa_job(struct xe_gt *gt, struct xe_exec_queue *q)
please notice that xe_devcoredump doesn't have any kind of locking
mechanism, because it relies on the serialization of the gt_reset.
Once you start calling from other places, then we should probably
add some data protection there.
But also, maybe we should define and print some kind of 'type' var
that is and argument to xe_devcoredump() and that gets printed on
top to ensure that we have a clear indication from when they are
coming from a gt_reset and from other timeouts?
Cc: Maarten
> xe_bb_free(bb, NULL);
> if (timeout < 0)
> return timeout;
> - else if (!timeout)
> + else if (!timeout) {
> + xe_devcoredump(q);
> return -ETIME;
> + }
>
> return 0;
> }
> --
> 2.34.1
>
next prev parent reply other threads:[~2023-10-04 13:40 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-26 21:20 [Intel-xe] [PATCH 1/2] drm/xe: Print devcoredump to drm_info Stuart Summers
2023-09-26 21:20 ` [Intel-xe] [PATCH 2/2] drm/xe: Add coredump to wa_bb timeouts Stuart Summers
2023-10-04 13:40 ` Rodrigo Vivi [this message]
2023-10-05 15:39 ` Summers, Stuart
2023-09-26 21:23 ` [Intel-xe] ✓ CI.Patch_applied: success for series starting with [1/2] drm/xe: Print devcoredump to drm_info Patchwork
2023-09-26 21:23 ` [Intel-xe] ✓ CI.checkpatch: " Patchwork
2023-09-26 21:24 ` [Intel-xe] ✓ CI.KUnit: " Patchwork
2023-09-26 21:31 ` [Intel-xe] ✓ CI.Build: " Patchwork
2023-09-26 21:32 ` [Intel-xe] ✓ CI.Hooks: " Patchwork
2023-09-26 21:33 ` [Intel-xe] ✓ CI.checksparse: " Patchwork
2023-09-26 22:05 ` [Intel-xe] ✓ CI.BAT: " Patchwork
2023-10-04 13:37 ` [Intel-xe] [PATCH 1/2] " Rodrigo Vivi
2023-10-05 15:38 ` Summers, Stuart
2023-10-05 16:13 ` Rodrigo Vivi
2023-10-05 16:26 ` Summers, Stuart
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=ZR1rWD6BZgDOk6+3@intel.com \
--to=rodrigo.vivi@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=stuart.summers@intel.com \
/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