Re: [PATCH v3] drm/xe/guc: Demote uncorrectable local error log on CRI

[Rodrigo Vivi <rodrigo.vivi@intel.com>]

On Fri, Oct 16, 2026 at 03:37:00PM -0700, Matt Roper wrote:
> On Tue, Oct 13, 2026 at 10:22:57AM +0530, Tauro, Riana wrote:
> > 
> > On 13-10-2026 09:04, Varun Gupta wrote:
> > > The UNCORRECTABLE_LOCAL_ERROR notification sent by the GuC indicates a
> > > local, queue-level context termination rather than a global device or
> > > driver failure. On CRI, due to a hardware limitation, the platform cannot
> > > distinguish GT translation faults from true RAS conditions, meaning
> > > standard workloads routinely trigger this error.
> > > 
> > > Printing this at ERROR level is too noisy and causes false-positive
> > > dmesg-warn failures in CI. Demote the log level to INFO for CRI.
> > > 
> > > v3:
> > >    - Limit the demotion to CRI and add comment explaining the HW limitation
> > >      (Rodrigo)
> > > v2:
> > >    - Also ratelimit the GUC_ID_UNKNOWN to match the CAT error handler.
> > >      (Himal)
> > > 
> > > Fixes: 4e57574fa3a3 ("drm/xe/guc: Handle GuC local uncorrectable error notifications")
> > > Signed-off-by: Varun Gupta <varun.gupta@intel.com>
> > > ---
> > >   drivers/gpu/drm/xe/xe_guc_submit.c | 18 ++++++++++++++----
> > >   1 file changed, 14 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/xe/xe_guc_submit.c b/drivers/gpu/drm/xe/xe_guc_submit.c
> > > index 7ce73489c35f..dc5b6b98ffc2 100644
> > > --- a/drivers/gpu/drm/xe/xe_guc_submit.c
> > > +++ b/drivers/gpu/drm/xe/xe_guc_submit.c
> > > @@ -3585,7 +3585,7 @@ int xe_guc_uncorrectable_error_handler(struct xe_guc *guc, u32 *msg, u32 len)
> > >   	guc_id = msg[0];
> > >   	if (guc_id == GUC_ID_UNKNOWN) {
> > > -		xe_gt_err(gt, "GuC: Uncorrectable local error with unknown GuC id\n");
> > > +		xe_gt_err_ratelimited(gt, "GuC: Uncorrectable local error with unknown GuC id\n");
> > >   		return 0;
> > >   	}
> > > @@ -3593,9 +3593,19 @@ int xe_guc_uncorrectable_error_handler(struct xe_guc *guc, u32 *msg, u32 len)
> > >   	if (unlikely(!q))
> > >   		return -EPROTO;
> > > -	xe_gt_err(gt,
> > > -		  "GuC: Uncorrectable local error! guc_id=%d class=%s, logical_mask=0x%x",
> > > -		  guc_id, xe_hw_engine_class_to_str(q->class), q->logical_mask);
> > > +	/*
> > > +	 * On CRI, the hardware cannot distinguish GT translation faults
> > > +	 * from true RAS conditions. Demote to info to avoid false-positive
> > > +	 * hardware error logs.
> > > +	 */
> > > +	if (gt_to_xe(gt)->info.platform == XE_CRESCENTISLAND)
> > > +		xe_gt_info(gt,
> > > +			   "GuC: Uncorrectable local error! guc_id=%d class=%s, logical_mask=0x%x",
> > > +			   guc_id, xe_hw_engine_class_to_str(q->class), q->logical_mask);
> > 
> > Shouldn't you be using ci ignore dmesg in test rather than demote an error
> > log?
> 
> I don't think CI is really the main concern here.  Giving unprivileged
> userspace clients a way to trigger new dmesg messages above DEBUG level
> on demand is generally considered a security concern and must be
> avoided.  So even the 'info' demotion here probably isn't far enough; I
> think this needs to go all the way down xe_gt_dbg() to make sure this is
> safe.  Otherwise we're hiding the CI failures but not fixing the real
> problem.

right, let's not hide this in IGT. My only ask was to have this CRI specific
with a comment explaining why.
But I don't have strong feelings about the _info vs _dbg... But likely
_dbg is better based on what Matt told.

Varun, are you sending another revision changing to _dbg? if no, why?

Thanks,
Rodrigo.

> 
> The fact that there isn't currently a way for our driver to distinguish
> user-triggered software errors from real hardware errors is a serious
> problem.
> 
> 
> Matt
> 
> > 
> > Thanks
> > Riana
> > 
> > > +	else
> > > +		xe_gt_err(gt,
> > > +			  "GuC: Uncorrectable local error! guc_id=%d class=%s, logical_mask=0x%x",
> > > +			  guc_id, xe_hw_engine_class_to_str(q->class), q->logical_mask);
> > >   	trace_xe_guc_uncorrectable_error(q);
> 
> -- 
> Matt Roper
> Graphics Software Engineer
> Linux GPU Platform Enablement
> Intel Corporation