All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: <intel-xe@lists.freedesktop.org>
Cc: Riana Tauro <riana.tauro@intel.com>,
	Tejas Upadhyay <tejas.upadhyay@intel.com>,
	Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>,
	Badal Nilawar <badal.nilawar@intel.com>,
	Raag Jadav <raag.jadav@intel.com>,
	Mallesh Koujalagi <mallesh.koujalagi@intel.com>,
	Aravind Iddamsetty <aravind.iddamsetty@intel.com>
Subject: Re: [RFC] drm/xe/ras: Report one SIGID per device memory error
Date: Tue, 10 Nov 2026 11:41:48 -0500	[thread overview]
Message-ID: <avNJTNWehTuBaFVL@intel.com> (raw)
In-Reply-To: <20261109161733.3769906-2-rodrigo.vivi@intel.com>

On Mon, Nov 09, 2026 at 11:17:34AM -0500, Rodrigo Vivi wrote:
> handle_page_offline() logged each step as SIGID 202 RECOVERABLE, so a
> single double-bit ECC error produced several 202 lines whose severity
> disagreed with the CPER record emitted by handle_device_memory_errors().
> 
> Log those steps without a SIGID and leave the caller's 202 with CPER as
> the only report. Firmware failures keep SIGID 105.
> 
> Cc: Riana Tauro <riana.tauro@intel.com>
> Cc: Tejas Upadhyay <tejas.upadhyay@intel.com>
> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
> Cc: Badal Nilawar <badal.nilawar@intel.com>
> Cc: Raag Jadav <raag.jadav@intel.com>
> Cc: Mallesh Koujalagi <mallesh.koujalagi@intel.com>
> Cc: Aravind Iddamsetty <aravind.iddamsetty@intel.com>
> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> ---
> 
> AI generated and untested.
> 
> Aiming to solve the discussion:
> https://lore.kernel.org/intel-xe/520a56ea-40a6-47bd-84a0-be5cf604e5e7@intel.com/#r
> 
> I agree with Badal that we should reduce the noise in the mempage-offline
> that is only bringing multiple entries of the same and then emmit only a single
> SIGID and a single CPER for it.

Please ignore this and let's focus on a real one that has the same goal:
https://lore.kernel.org/intel-xe/20261104090701.1748619-2-riana.tauro@intel.com

Sorry for the duplication and the noise. I just noticed this other one just
now in my inbox.

> 
>  drivers/gpu/drm/xe/xe_ras.c | 32 +++++++++++++-------------------
>  1 file changed, 13 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/xe/xe_ras.c b/drivers/gpu/drm/xe/xe_ras.c
> index 2c01c183d02b..5b13daf972ba 100644
> --- a/drivers/gpu/drm/xe/xe_ras.c
> +++ b/drivers/gpu/drm/xe/xe_ras.c
> @@ -269,11 +269,9 @@ static int send_page_offline_cmd(struct xe_device *xe, u64 page_address,
>  	request.action = action;
>  
>  	if (action == XE_RAS_PAGE_ACTION_OFFLINE)
> -		xe_log_err(xe, DEVICE_MEMORY, 0, "Requesting firmware to offline page 0x%llx\n",
> -			   page_address);
> +		xe_dbg(xe, "Requesting firmware to offline page 0x%llx\n", page_address);
>  	else
> -		xe_log_err(xe, DEVICE_MEMORY, 0, "Requesting firmware to remove page 0x%llx from queue\n",
> -			   page_address);
> +		xe_dbg(xe, "Requesting firmware to remove page 0x%llx from queue\n", page_address);
>  
>  	xe_sysctrl_create_command(&command, XE_SYSCTRL_GROUP_GFSP, XE_SYSCTRL_CMD_PAGE_OFFLINE,
>  				  &request, sizeof(request), &response, sizeof(response));
> @@ -326,7 +324,7 @@ static int handle_page_offline(struct xe_device *xe, u64 page_address, bool noti
>  	/* User policy set to disable page offlining */
>  	if (xe_ras_get_disable_vram_page_offline(xe)) {
>  		action = XE_RAS_PAGE_ACTION_REMOVE;
> -		xe_log_err(xe, DEVICE_MEMORY, -EOPNOTSUPP, "User policy set to disable page offlining\n");
> +		xe_info(xe, "User policy set to disable page offlining\n");
>  		goto notify;
>  	}
>  
> @@ -346,14 +344,12 @@ static int handle_page_offline(struct xe_device *xe, u64 page_address, bool noti
>  	switch (ret) {
>  	case 0:
>  		action = XE_RAS_PAGE_ACTION_REMOVE;
> -		xe_log_err(xe, DEVICE_MEMORY, ret,
> -			   "Poison detected at physical address 0x%llx, page soft-offlined\n",
> -			   page_address);
> +		xe_info(xe, "Poison detected at physical address 0x%llx, page soft-offlined\n",
> +			page_address);
>  		break;
>  	case -EIO:
> -		xe_log_err(xe, DEVICE_MEMORY, ret,
> -			   "Poison detected at physical address 0x%llx, page belongs to critical BO and cannot be soft-offlined\n",
> -			   page_address);
> +		xe_err(xe, "Poison detected at physical address 0x%llx, page belongs to critical BO and cannot be soft-offlined\n",
> +		       page_address);
>  		return ret;
>  	case -EEXIST:
>  		if (xa_load(&state->offlined_pages, page_address >> XE_PTE_SHIFT))
> @@ -361,18 +357,16 @@ static int handle_page_offline(struct xe_device *xe, u64 page_address, bool noti
>  		else
>  			action = XE_RAS_PAGE_ACTION_OFFLINE;
>  
> -		xe_log_err(xe, DEVICE_MEMORY, ret,
> -			   "Double-bit ECC error detected at physical address 0x%llx, page soft-offlined\n",
> -			   page_address);
> +		xe_info(xe, "Double-bit ECC error detected at physical address 0x%llx, page soft-offlined\n",
> +			page_address);
>  		break;
>  	case -ENOMEM:
> -		xe_log_err(xe, DEVICE_MEMORY, ret,
> -			   "Poison detected at physical address 0x%llx, failed to soft-offline\n",
> -			   page_address);
> +		xe_err(xe, "Poison detected at physical address 0x%llx, failed to soft-offline\n",
> +		       page_address);
>  		return ret;
>  	default:
> -		xe_log_err(xe, DEVICE_MEMORY, ret, "Failed to handle address fault at physical address 0x%llx\n",
> -			   page_address);
> +		xe_err(xe, "Failed to handle address fault at physical address 0x%llx: %d\n",
> +		       page_address, ret);
>  		return 0;
>  	}
>  
> -- 
> 2.55.0
> 

      parent reply	other threads:[~2026-11-10 16:42 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-09 16:17 [RFC] drm/xe/ras: Report one SIGID per device memory error Rodrigo Vivi
2026-11-09 17:08 ` ✓ CI.KUnit: success for " Patchwork
2026-11-09 17:39 ` ✓ Xe.CI.BAT: " Patchwork
2026-11-10 16:41 ` Rodrigo Vivi [this message]

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=avNJTNWehTuBaFVL@intel.com \
    --to=rodrigo.vivi@intel.com \
    --cc=aravind.iddamsetty@intel.com \
    --cc=badal.nilawar@intel.com \
    --cc=himal.prasad.ghimiray@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=mallesh.koujalagi@intel.com \
    --cc=raag.jadav@intel.com \
    --cc=riana.tauro@intel.com \
    --cc=tejas.upadhyay@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.