Re: [PATCH] drm/xe/guc: skip TDR timeout check when ctx_timestamp is 0 or 1

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Resetting `job->sample_timestamp` to `U64_MAX` when `ctx_timestamp <= 1` unconditionally bypasses the TDR watchdog if the GPU hangs during context restore, causing an infinite loop that completely disables hang recovery.
--

commit e50d47eb7a620614e04b8e05f251f148a49a7005
Author: Jia Yao <jia.yao@intel.com>

drm/xe/guc: skip TDR timeout check when ctx_timestamp is 0 or 1

This commit updates the TDR timeout check to skip when ctx_timestamp
is 0 or 1. It resets the sampling baseline instead, under the assumption
that the timestamp is not yet valid.

> diff --git a/drivers/gpu/drm/xe/xe_guc_submit.c b/drivers/gpu/drm/xe/xe_guc_submit.c
> --- a/drivers/gpu/drm/xe/xe_guc_submit.c
> +++ b/drivers/gpu/drm/xe/xe_guc_submit.c
[ ... ]
> @@ -1428,6 +1428,20 @@ static bool check_timeout(struct xe_exec_queue *q, struct xe_sched_job *job)
>  		return xe_sched_invalidate_job(job, 0);
>  	}
>  
> +	/*
> +	 * A ctx_timestamp of 0 or 1 indicates an invalid timestamp:
> +	 * - 1 (CONTEXT_ACTIVE) is the cookie written by the WA BB immediately
> +	 *   after a full context restore, before the spinner has run.
> +	 * - 0 can occur when lrc->ctx_timestamp shadow is uninitialized or was
> +	 *   last updated while the context was being restored.
> +	 * In both cases the timestamp is not yet valid, so reset the sampling
> +	 * baseline and wait for the next check_timeout() call.
> +	 */
> +	if (ctx_timestamp <= 1) {
> +		job->sample_timestamp = U64_MAX;
> +		return false;
> +	}
> +

[Severity: High]
Does this unconditionally bypass the TDR watchdog if the GPU hangs during a
context restore?

If the hardware stalls while ctx_timestamp is 0 or 1 (e.g., during context
restore or while the WA BB is executing), check_timeout() will continuously
reset job->sample_timestamp to U64_MAX and return false.

On all subsequent TDR ticks, ctx_timestamp will still be 0 or 1, which does
not equal U64_MAX. Won't this repeat the reset and return false indefinitely,
preventing the DRM scheduler from ever invalidating the job and triggering a
GPU reset?

>  	job->sample_timestamp = ctx_timestamp;
>  	ctx_job_timestamp = xe_lrc_ctx_job_timestamp(q->lrc[0]);
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260904180943.3455267-1-jia.yao@intel.com?part=1