From: Michal Wajdeczko <michal.wajdeczko@intel.com>
To: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Cc: <intel-xe@lists.freedesktop.org>, <rodrigo.vivi@intel.com>,
<badal.nilawar@intel.com>, <riana.tauro@intel.com>,
<aravind.iddamsetty@linux.intel.com>,
<mallesh.koujalagi@intel.com>
Subject: Re: [PATCH 4/4] drm/xe/ras: Report CSC errors using SIGID
Date: Sat, 15 Aug 2026 09:59:24 +0200 [thread overview]
Message-ID: <a228f329-abd6-4a4b-bf1a-24db61084d10@intel.com> (raw)
In-Reply-To: <an9eDL/b0zkDOCtd@soc-5CG1426VCC.clients.intel.com>
On 8/14/2026 8:27 PM, Umesh Nerlige Ramappa wrote:
> On Wed, Aug 12, 2026 at 09:52:22PM +0200, Michal Wajdeczko wrote:
>>
>>
>> On 8/12/2026 1:52 AM, Umesh Nerlige Ramappa wrote:
>>> Use xe_log_err() to report CSC errors using SIGID.
>>>
>>> Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
>>> ---
>>> drivers/gpu/drm/xe/xe_ras.c | 5 ++---
>>> 1 file changed, 2 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/xe/xe_ras.c b/drivers/gpu/drm/xe/xe_ras.c
>>> index d1aa3794f2e0..e50ab49bce5a 100644
>>> --- a/drivers/gpu/drm/xe/xe_ras.c
>>> +++ b/drivers/gpu/drm/xe/xe_ras.c
>>> @@ -283,9 +283,8 @@ static u8 handle_soc_internal_errors(struct xe_device *xe, struct xe_ras_error_a
>>> * is required.
>>> */
>>> if (csc_error->hec_fw_error) {
>>> - xe_err(xe, "[RAS]: CSC %s detected: 0x%x\n",
>>> - sev_to_str(counter->common.severity),
>>> - csc_error->hec_fw_error);
>>> + xe_log_err(xe, SOC, 0, "[RAS]: CSC %s detected: 0x%x\n",
>>> + sev_to_str(counter->common.severity), csc_error->hec_fw_error);
>>
>> hmm, it was assumed that for HW errors we will use 12 byte data
>> while xe_log_err is mostly for the SW errors where we use errno
>
> Not sure I understand what the 12 bytes data is.
IIUC it would be struct xe_ras_error_class
>
>>
>> do we still need to use "RAS" prefix ?
>>
>> maybe we should add component XE_LOG_COMPONENT_CSC with SIGID_SOC_INTERNAL ?
>>
>> shouldn't we use common.severity to select right xe_log/CPER severity ?
>
> Not sure how to use this macro to do that though. I thought severity was automatically handled in the backend.
if you plan to report errno-like SW errors from the CSC FW,
then IMO we should add new CSC component in abi/xe_log_abi.h
with XE_SIGID_DEVICE_FW:
+ define(DRIVER_FIRMWARE, 18, CSC, DEVICE_FW, "CSC") \
then you can use
xe_log_err(xe, CSC, err, "detected: %#x\n", csc_error->hec_fw_error);
xe_log_err_fatal(xe, CSC, err, "detected: %#x\n", csc_error->hec_fw_error);
or if you can match counter severity with CPER severity:
cper_sev = to_cper_sev(counter->common.severity);
xe_log_comp(xe, cper_sev, CSC, ERR_PTR(err), 0, "detected: %#x\n", csc_error->hec_fw_error);
but if that error is representing HW SIGID - SOC_INTERNAL
then I guess it is expected that xe_ras_error_class should
be passed to xe_log() using:
struct xe_ras_error_class data;
xe_log_comp(xe, cper_sev, SOC_INTERNAL, &data, sizeof(data), "...\n");
to allow proper CPER record generation
>
> Thanks,
> Umesh
>>
>>> xe_survivability_mode_runtime_enable(xe);
>>> return XE_RAS_RECOVERY_ACTION_DISCONNECT;
>>> }
>>
next prev parent reply other threads:[~2026-08-15 7:59 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-11 23:52 [PATCH 0/4] Use SIGID API for PCODE and CSC Umesh Nerlige Ramappa
2026-08-11 23:52 ` [PATCH 1/4] drm/xe/log: DO NOT REVIEW Umesh Nerlige Ramappa
2026-08-11 23:52 ` [PATCH 2/4] drm/xe/pcode: Use int instead of u32 for mailbox status Umesh Nerlige Ramappa
2026-08-12 0:04 ` sashiko-bot
2026-08-11 23:52 ` [PATCH 3/4] drm/xe/pcode: Report pcode errors using SIGID Umesh Nerlige Ramappa
2026-08-12 0:01 ` sashiko-bot
2026-08-12 13:35 ` Nilawar, Badal
2026-08-12 18:07 ` Umesh Nerlige Ramappa
2026-08-12 19:45 ` Michal Wajdeczko
2026-08-13 16:53 ` Umesh Nerlige Ramappa
2026-08-11 23:52 ` [PATCH 4/4] drm/xe/ras: Report CSC " Umesh Nerlige Ramappa
2026-08-12 19:52 ` Michal Wajdeczko
2026-08-14 18:27 ` Umesh Nerlige Ramappa
2026-08-15 7:59 ` Michal Wajdeczko [this message]
2026-08-18 22:52 ` Umesh Nerlige Ramappa
2026-08-11 23:59 ` ✗ CI.checkpatch: warning for Use SIGID API for PCODE and CSC Patchwork
2026-08-12 0:00 ` ✓ CI.KUnit: success " Patchwork
2026-08-12 0:38 ` ✓ Xe.CI.BAT: " Patchwork
2026-08-12 1:48 ` ✓ Xe.CI.FULL: " 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=a228f329-abd6-4a4b-bf1a-24db61084d10@intel.com \
--to=michal.wajdeczko@intel.com \
--cc=aravind.iddamsetty@linux.intel.com \
--cc=badal.nilawar@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=mallesh.koujalagi@intel.com \
--cc=riana.tauro@intel.com \
--cc=rodrigo.vivi@intel.com \
--cc=umesh.nerlige.ramappa@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