Re: [PATCH] drm/xe: Reduce LRC timestamp stuck message on VFs to notice

[Matthew Brost <matthew.brost@intel.com>]

On Wed, Jan 14, 2026 at 01:43:14PM -0700, Summers, Stuart wrote:
> On Wed, 2026-01-14 at 12:38 -0800, Matthew Brost wrote:
> > On Wed, Jan 14, 2026 at 01:25:55PM -0700, Summers, Stuart wrote:
> > > On Wed, 2026-01-14 at 10:49 -0800, Matthew Brost wrote:
> > > > An LRC timestamp getting stuck is a somewhat normal occurrence.
> > > > If a
> > > > single VF submits a job that does not get timesliced, the LRC
> > > > timestamp
> > > > will not increment. Reduce the LRC timestamp stuck message on VFs
> > > > to
> > > > notice (same log level as job timeout) to avoid false CI bugs in
> > > > tests
> > > > where a VF submits a job that does not get timesliced.
> > > 
> > > Ok and if this happens and there is an actual problem, the queue
> > > will
> > > be banned it looks like from the earlier patch, so should still be
> > > ok. 
> > > 
> > > My only question is why not move both cases (VF and non-VF) to
> > > notice?
> > 
> > The non-VF case the LRC timestamp should always be moving, if it
> > isn't
> > something has badly gone wrong and CI should notify us of the error.
> 
> Ok but shouldn't the job timeout generally be the same? (should we
> change that timeout to warn?)
> 

A timeout message is at notice level. CI understands that, but the warn
level here is triggering CI failures on VFs where this message is
expected in addition to the timeout message. For non-VFs, we do not
expect this message for job timeouts.

> And sorry if this is a basic question... but why isn't that the case
> for VF too? Because on the VF side we are issuing resets as part of the

The algorithm to accurately sample the LRC timestamp relies on access to
the engine MMIO timestamp, which a VF does not have. I’m told we can
make some configuration change to allow VF access to this register —
I’ll follow up on that, but until then, let’s not break CI.

Matt

> submission flow normally? Or because we want to make sure the resets
> from one VF are hidden from another VF?
> 
> Thanks,
> Stuart
> 
> > 
> > Matt
> > 
> > > Is the idea that in the non-VF case, the reset is already an error
> > > and
> > > so the extra warn is ok? But in that case I'd already expect some
> > > other
> > > error message to trigger CI (like the engine reset notification
> > > from
> > > GuC). So the extra information here really isn't doing a whole lot
> > > more
> > > from a warning level (CI triggering) perspective.
> > > 
> > > Thanks,
> > > Stuart
> > > 
> > > > 
> > > > Closes:
> > > > https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7032
> > > > Fixes: bb63e7257e63 ("drm/xe: Avoid toggling schedule state to
> > > > check
> > > > LRC timestamp in TDR")
> > > > Suggested-by: Daniele Ceraolo Spurio
> > > > <daniele.ceraolospurio@intel.com>
> > > > Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> > > > ---
> > > >  drivers/gpu/drm/xe/xe_guc_submit.c | 11 ++++++++---
> > > >  1 file changed, 8 insertions(+), 3 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/xe/xe_guc_submit.c
> > > > b/drivers/gpu/drm/xe/xe_guc_submit.c
> > > > index be8fa76baf1d..0311c89107f9 100644
> > > > --- a/drivers/gpu/drm/xe/xe_guc_submit.c
> > > > +++ b/drivers/gpu/drm/xe/xe_guc_submit.c
> > > > @@ -1319,9 +1319,14 @@ static bool check_timeout(struct
> > > > xe_exec_queue
> > > > *q, struct xe_sched_job *job)
> > > >  
> > > >         ctx_timestamp = lower_32_bits(xe_lrc_timestamp(q-
> > > > >lrc[0]));
> > > >         if (ctx_timestamp == job->sample_timestamp) {
> > > > -               xe_gt_warn(gt, "Check job timeout: seqno=%u,
> > > > lrc_seqno=%u, guc_id=%d, timestamp stuck",
> > > > -                          xe_sched_job_seqno(job),
> > > > xe_sched_job_lrc_seqno(job),
> > > > -                          q->guc->id);
> > > > +               if (IS_SRIOV_VF(gt_to_xe(gt)))
> > > > +                       xe_gt_notice(gt, "Check job timeout:
> > > > seqno=%u, lrc_seqno=%u, guc_id=%d, timestamp stuck",
> > > > +                                    xe_sched_job_seqno(job),
> > > > +                                    xe_sched_job_lrc_seqno(job),
> > > > q-
> > > > > guc->id);
> > > > +               else
> > > > +                       xe_gt_warn(gt, "Check job timeout:
> > > > seqno=%u,
> > > > lrc_seqno=%u, guc_id=%d, timestamp stuck",
> > > > +                                  xe_sched_job_seqno(job),
> > > > +                                  xe_sched_job_lrc_seqno(job),
> > > > q-
> > > > > guc->id);
> > > >  
> > > >                 return xe_sched_invalidate_job(job, 0);
> > > >         }
> > > 
>