Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: John Harrison <john.c.harrison@intel.com>
To: Matthew Brost <matthew.brost@intel.com>
Cc: <intel-xe@lists.freedesktop.org>
Subject: Re: [PATCH] drm/xe: Do not print engine reset message on a killed queue
Date: Fri, 9 May 2025 12:13:01 -0700	[thread overview]
Message-ID: <58717de2-2269-4d02-b8ea-7e02eaa0e1eb@intel.com> (raw)
In-Reply-To: <aB2am1IYTbIU6j/u@lstrano-desk.jf.intel.com>

On 5/8/2025 11:03 PM, Matthew Brost wrote:
> On Thu, May 08, 2025 at 04:03:56PM -0700, John Harrison wrote:
>> On 5/8/2025 12:09 PM, Matthew Brost wrote:
>>> When an app is ctrl-c (killed) any queues running on the GPU have their
>>> preemption timeout set to the minimum value and scheduling is disabled.
>>> If the queue has something active on the GPU it is very likely for the
>>> GuC will trigger an engine reset resulting in the engine reset message
>>> being printed when this is fully expected. Do not print the engine reset
>>> message on queues which have been killed.
>>>
>>> Reported-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
>>> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/4904
>>> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
>>> ---
>>>    drivers/gpu/drm/xe/xe_guc_submit.c | 5 +++--
>>>    1 file changed, 3 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/xe/xe_guc_submit.c b/drivers/gpu/drm/xe/xe_guc_submit.c
>>> index 369be36f7dc5..efff462ddd75 100644
>>> --- a/drivers/gpu/drm/xe/xe_guc_submit.c
>>> +++ b/drivers/gpu/drm/xe/xe_guc_submit.c
>>> @@ -2005,8 +2005,9 @@ int xe_guc_exec_queue_reset_handler(struct xe_guc *guc, u32 *msg, u32 len)
>>>    	if (unlikely(!q))
>>>    		return -EPROTO;
>>> -	xe_gt_info(gt, "Engine reset: engine_class=%s, logical_mask: 0x%x, guc_id=%d",
>>> -		   xe_hw_engine_class_to_str(q->class), q->logical_mask, guc_id);
>>> +	if (!exec_queue_killed(q))
>>> +		xe_gt_info(gt, "Engine reset: engine_class=%s, logical_mask: 0x%x, guc_id=%d",
>>> +			   xe_hw_engine_class_to_str(q->class), q->logical_mask, guc_id);
>> Maybe make it an xe_gt_dbg in the case of a killed queue? It is still useful
>> to see such messages when triaging CI failures to get an idea of what is
>> going on behind the scenes.
>>
> I had thought about this, should be fine as long as this isn't spamming
> normal production kernels dmesg. I would assume xe_gt_dbg would not show
> up. I did the same thing for job timeout message in this patch - just
> dropped it on killed queues maybe I should be xe_gt_dbg message there
> too?
Yeah, for CI runs it is helpful to see when and why things are being 
killed. Especially when tracking down issues with context clean up and such!

And yeah, debug level does not show up by default. CI explicitly bumps 
the default log level to make it show up. And that brings on way more 
output from the display side than the i915 or Xe drivers ever produce!

John.

>
> Matt
>
>> John.
>>
>>>    	trace_xe_exec_queue_reset(q);


  reply	other threads:[~2025-05-09 19:13 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-08 19:09 [PATCH] drm/xe: Do not print engine reset message on a killed queue Matthew Brost
2025-05-08 19:15 ` ✓ CI.Patch_applied: success for " Patchwork
2025-05-08 19:15 ` ✓ CI.checkpatch: " Patchwork
2025-05-08 19:16 ` ✓ CI.KUnit: " Patchwork
2025-05-08 19:24 ` ✓ CI.Build: " Patchwork
2025-05-08 19:27 ` ✓ CI.Hooks: " Patchwork
2025-05-08 19:28 ` ✓ CI.checksparse: " Patchwork
2025-05-08 20:25 ` ✓ Xe.CI.BAT: " Patchwork
2025-05-08 21:36 ` [PATCH] " Cavitt, Jonathan
2025-05-08 22:00   ` Matthew Brost
2025-05-09 14:55     ` Cavitt, Jonathan
2025-05-08 23:03 ` John Harrison
2025-05-09  6:03   ` Matthew Brost
2025-05-09 19:13     ` John Harrison [this message]
2025-05-09 12:22 ` ✗ Xe.CI.Full: failure for " Patchwork
2025-05-26 19:06 ` ✓ CI.Patch_applied: success " Patchwork
2025-05-26 19:07 ` ✓ CI.checkpatch: " Patchwork
2025-05-26 19:08 ` ✓ CI.KUnit: " Patchwork
2025-05-26 19:18 ` ✓ CI.Build: " 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=58717de2-2269-4d02-b8ea-7e02eaa0e1eb@intel.com \
    --to=john.c.harrison@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=matthew.brost@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