[PATCH 1/1] drm/xe/survivability: broadcast dmesg when engaging survivability

[PATCH 1/1] drm/xe/survivability: broadcast dmesg when engaging survivability

[Alan Previn]

Today, when the driver faces issues with early pcode errors
and attempts to enter survivabilty (when explicitly requested)
it may either succeed or fail (latter being possible due to
underlying subsystem blockers). During this flow the driver remains
loaded and completely silent. No messages indicate that it may need
or it attempted and succeeded or it attempted and failed, to enter
survivability mode. This patch adds some awareness in dmesg.

Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com>
---
 drivers/gpu/drm/xe/xe_device.c | 38 +++++++++++++++++++++++++---------
 1 file changed, 28 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
index a07655b4c7a9..45ff28ed41a4 100644
--- a/drivers/gpu/drm/xe/xe_device.c
+++ b/drivers/gpu/drm/xe/xe_device.c
@@ -710,7 +710,8 @@ static int xe_device_vram_alloc(struct xe_device *xe)
  */
 int xe_device_probe_early(struct xe_device *xe)
 {
-	int err;
+	int err, pcode_err;
+	bool survival_requested;
 
 	xe_wa_device_init(xe);
 	xe_wa_process_device_oob(xe);
@@ -734,20 +735,37 @@ int xe_device_probe_early(struct xe_device *xe)
 	 * initialization is complete. Until done, any MMIO or lmem access from
 	 * the driver will be blocked
 	 */
-	err = xe_pcode_probe_early(xe);
-	if (err || xe_survivability_mode_is_requested(xe)) {
-		int save_err = err;
-
+	pcode_err = xe_pcode_probe_early(xe);
+	survival_requested = xe_survivability_mode_is_requested(xe);
+	if (pcode_err || survival_requested) {
 		/*
 		 * Try to leave device in survivability mode if device is
 		 * possible, but still return the previous error for error
 		 * propagation
 		 */
-		err = xe_survivability_mode_boot_enable(xe);
-		if (err)
-			return err;
-
-		return save_err;
+		int survive_err = xe_survivability_mode_boot_enable(xe);
+
+		if (survive_err) {
+			if (pcode_err && survival_requested)
+				xe_err(xe, "Early pcode err(%pe), survivability requested but unavailable(%pe)\n",
+				       ERR_PTR(pcode_err), ERR_PTR(survive_err));
+			else if (!pcode_err)
+				xe_warn(xe, "Early pcode ok, survivability requested but unavailable(%pe)\n",
+					ERR_PTR(survive_err));
+			else
+				xe_warn(xe, "Early pcode err(%pe), survivability not requested and unavailable(%pe)\n",
+					ERR_PTR(pcode_err), ERR_PTR(survive_err));
+			return survive_err;
+		}
+		if (pcode_err && survival_requested)
+			xe_notice(xe, "Early pcode err(%pe), survivability requested\n",
+				  ERR_PTR(pcode_err));
+		else if (!pcode_err)
+			xe_notice(xe, "Early pcode ok but survivability requested\n");
+		else
+			xe_warn(xe, "Early pcode err(%pe), survivability not requested. Consider xe_configfs\n",
+				ERR_PTR(pcode_err));
+		return pcode_err;
 	}
 
 	/*

base-commit: 55c6bb0b4d006ee415abe9f048014f7bcc90ae6f
-- 
2.43.0

Re: [PATCH 1/1] drm/xe/survivability: broadcast dmesg when engaging survivability

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] drm/xe: unreachable branch and wrong log in xe_device_probe_early()
--

commit 9d8c24e19d32b177027b35cc906adcdcf29823ef
Author: Alan Previn <alan.previn.teres.alexis@intel.com>

drm/xe/survivability: broadcast dmesg when engaging survivability

This commit adds dmesg logging in xe_device_probe_early() when the driver
encounters early pcode errors or when survivability mode is requested.

> diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
> index e1979bbcf7bc6..49df992253a9a 100644
> --- a/drivers/gpu/drm/xe/xe_device.c
> +++ b/drivers/gpu/drm/xe/xe_device.c
> @@ -702,7 +702,8 @@ static int xe_device_vram_alloc(struct xe_device *xe)
>   */
>  int xe_device_probe_early(struct xe_device *xe)
>  {
> -	int err;
> +	int err, pcode_err;
> +	bool survival_requested;
>  
>  	xe_wa_device_init(xe);
>  	xe_wa_process_device_oob(xe);
> @@ -726,20 +727,37 @@ int xe_device_probe_early(struct xe_device *xe)
>  	 * initialization is complete. Until done, any MMIO or lmem access from
>  	 * the driver will be blocked
>  	 */
> -	err = xe_pcode_probe_early(xe);
> -	if (err || xe_survivability_mode_is_requested(xe)) {
> -		int save_err = err;
> -
> +	pcode_err = xe_pcode_probe_early(xe);
> +	survival_requested = xe_survivability_mode_is_requested(xe);
> +	if (pcode_err || survival_requested) {
>  		/*
>  		 * Try to leave device in survivability mode if device is
>  		 * possible, but still return the previous error for error
>  		 * propagation
>  		 */
> -		err = xe_survivability_mode_boot_enable(xe);
> -		if (err)
> -			return err;
> -
> -		return save_err;
> +		int survive_err = xe_survivability_mode_boot_enable(xe);
> +
> +		if (survive_err) {
> +			if (pcode_err && survival_requested)
> +				xe_err(xe, "Early pcode err(%pe), survivability requested but unavailable(%pe)\n",
> +				       ERR_PTR(pcode_err), ERR_PTR(survive_err));
> +			else if (!pcode_err)
> +				xe_warn(xe, "Early pcode ok, survivability requested but unavailable(%pe)\n",
> +					ERR_PTR(survive_err));
> +			else
> +				xe_warn(xe, "Early pcode err(%pe), survivability not requested and unavailable(%pe)\n",
> +					ERR_PTR(pcode_err), ERR_PTR(survive_err));
> +			return survive_err;
> +		}
> +		if (pcode_err && survival_requested)
> +			xe_notice(xe, "Early pcode err(%pe), survivability requested\n",
> +				  ERR_PTR(pcode_err));
> +		else if (!pcode_err)
> +			xe_notice(xe, "Early pcode ok but survivability requested\n");
> +		else
> +			xe_warn(xe, "Early pcode err(%pe), survivability not requested. Consider xe_configfs\n",
> +				ERR_PTR(pcode_err));

[Severity: Medium]
Can the first else branch inside if (survive_err) ever be reached, and does
the second else branch log a misleading message on unsupported platforms?

In drivers/gpu/drm/xe/xe_survivability_mode.c,
xe_survivability_mode_boot_enable() immediately re-checks
xe_survivability_mode_is_requested(xe) and returns 0 when it is false:

int xe_survivability_mode_boot_enable(struct xe_device *xe)
{
	struct xe_survivability *survivability = &xe->survivability;
	struct pci_dev *pdev = to_pci_dev(xe->drm.dev);

	if (!xe_survivability_mode_is_requested(xe))
		return 0;

And xe_survivability_mode_is_requested() returns false both when
survivability is not requested and when the platform or VF does not support
survivability mode:

bool xe_survivability_mode_is_requested(struct xe_device *xe)
{
	...
	if (!IS_DGFX(xe) || IS_SRIOV_VF(xe) || xe->info.platform < XE_BATTLEMAGE)
		return false;

Because xe_survivability_mode_boot_enable() returns 0 whenever
xe_survivability_mode_is_requested() is false:

1. In xe_device_probe_early(), when pcode_err is non-zero and
   survival_requested is false, survive_err will be 0 (unless the redundant
   second call to xe_survivability_mode_is_requested() reads a changed
   configfs or PCODE_SCRATCH(0) state, in which case survivability was
   actually requested). That makes the "Early pcode err(%pe), survivability
   not requested and unavailable(%pe)" branch unreachable under normal
   execution.

2. On integrated GPUs, SR-IOV VFs, or dGPUs prior to XE_BATTLEMAGE where
   survivability mode is unsupported (and where xe_config_device_is_visible()
   in drivers/gpu/drm/xe/xe_configfs.c hides attr_survivability_mode), an
   early pcode failure will have survive_err == 0 and survival_requested ==
   false, falling through to log "Consider xe_configfs" even though the
   survivability_mode configfs attribute is not available on that device.

Should xe_survivability_mode_boot_enable() or its helper distinguish between
"unsupported" and "not requested", and avoid calling
xe_survivability_mode_is_requested() twice?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261023001827.170645-2-alan.previn.teres.alexis@intel.com?part=1

Re: [PATCH 1/1] drm/xe/survivability: broadcast dmesg when engaging survivability

[Teres Alexis, Alan Previn]

> 
alan: [snip]
> [Severity: Medium]
> Can the first else branch inside if (survive_err) ever be reached, and does
> the second else branch log a misleading message on unsupported platforms?
> 
> In drivers/gpu/drm/xe/xe_survivability_mode.c,
> xe_survivability_mode_boot_enable() immediately re-checks
> xe_survivability_mode_is_requested(xe) and returns 0 when it is false:
> 
> int xe_survivability_mode_boot_enable(struct xe_device *xe)
> {
> 	struct xe_survivability *survivability = &xe->survivability;
> 	struct pci_dev *pdev = to_pci_dev(xe->drm.dev);
> 
> 	if (!xe_survivability_mode_is_requested(xe))
> 		return 0;
> 
> And xe_survivability_mode_is_requested() returns false both when
> survivability is not requested and when the platform or VF does not support
> survivability mode:
> 
> bool xe_survivability_mode_is_requested(struct xe_device *xe)
> {
> 	...
> 	if (!IS_DGFX(xe) || IS_SRIOV_VF(xe) || xe->info.platform < XE_BATTLEMAGE)
> 		return false;
> 
> Because xe_survivability_mode_boot_enable() returns 0 whenever
> xe_survivability_mode_is_requested() is false:
> 
> 1. In xe_device_probe_early(), when pcode_err is non-zero and
>    survival_requested is false, survive_err will be 0 (unless the redundant
>    second call to xe_survivability_mode_is_requested() reads a changed
>    configfs or PCODE_SCRATCH(0) state, in which case survivability was
>    actually requested). That makes the "Early pcode err(%pe), survivability
>    not requested and unavailable(%pe)" branch unreachable under normal
>    execution.
> 
> 2. On integrated GPUs, SR-IOV VFs, or dGPUs prior to XE_BATTLEMAGE where
>    survivability mode is unsupported (and where xe_config_device_is_visible()
>    in drivers/gpu/drm/xe/xe_configfs.c hides attr_survivability_mode), an
>    early pcode failure will have survive_err == 0 and survival_requested ==
>    false, falling through to log "Consider xe_configfs" even though the
>    survivability_mode configfs attribute is not available on that device.
> 
> Should xe_survivability_mode_boot_enable() or its helper distinguish between
> "unsupported" and "not requested", and avoid calling
> xe_survivability_mode_is_requested() twice?
> 
> 

alan: Shasiko's points are valid. i dont want to refactor the original code and change the flow, so i'll only limit
the messages so its never reflecting an invalid case.

[PATCH 1/1] drm/xe/survivability: broadcast dmesg when engaging survivability

[Alan Previn]

Today, when the driver faces issues with early pcode errors
and attempts to enter survivabilty (when explicitly requested)
it may either succeed or fail (latter being possible due to
underlying subsystem blockers). During this flow the driver remains
loaded and completely silent. No messages indicate that it may need
or it attempted and succeeded or it attempted and failed, to enter
survivability mode. This patch adds some awareness in dmesg.

 v2 : Remove / modify messages to reflect underlying behavior. (Sashiko)

Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com>
---
 drivers/gpu/drm/xe/xe_device.c | 35 ++++++++++++++++++++++++----------
 1 file changed, 25 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
index a07655b4c7a9..23ee6f255205 100644
--- a/drivers/gpu/drm/xe/xe_device.c
+++ b/drivers/gpu/drm/xe/xe_device.c
@@ -710,7 +710,8 @@ static int xe_device_vram_alloc(struct xe_device *xe)
  */
 int xe_device_probe_early(struct xe_device *xe)
 {
-	int err;
+	int err, pcode_err;
+	bool survival_requested;
 
 	xe_wa_device_init(xe);
 	xe_wa_process_device_oob(xe);
@@ -734,20 +735,34 @@ int xe_device_probe_early(struct xe_device *xe)
 	 * initialization is complete. Until done, any MMIO or lmem access from
 	 * the driver will be blocked
 	 */
-	err = xe_pcode_probe_early(xe);
-	if (err || xe_survivability_mode_is_requested(xe)) {
-		int save_err = err;
-
+	pcode_err = xe_pcode_probe_early(xe);
+	survival_requested = xe_survivability_mode_is_requested(xe);
+	if (pcode_err || survival_requested) {
 		/*
 		 * Try to leave device in survivability mode if device is
 		 * possible, but still return the previous error for error
 		 * propagation
 		 */
-		err = xe_survivability_mode_boot_enable(xe);
-		if (err)
-			return err;
-
-		return save_err;
+		int survive_err = xe_survivability_mode_boot_enable(xe);
+
+		if (survive_err) {
+			if (pcode_err && survival_requested)
+				xe_err(xe, "Early pcode err(%pe), survivability requested but unavailable(%pe)\n",
+				       ERR_PTR(pcode_err), ERR_PTR(survive_err));
+			else if (!pcode_err)
+				xe_warn(xe, "Early pcode ok, survivability requested but unavailable(%pe)\n",
+					ERR_PTR(survive_err));
+			return survive_err;
+		}
+		if (pcode_err && survival_requested)
+			xe_notice(xe, "Early pcode err(%pe), survivability requested\n",
+				  ERR_PTR(pcode_err));
+		else if (!pcode_err)
+			xe_notice(xe, "Early pcode ok but survivability requested\n");
+		else
+			xe_warn(xe, "Early pcode err(%pe) but survivability not requested or unsupported\n",
+				ERR_PTR(pcode_err));
+		return pcode_err;
 	}
 
 	/*

base-commit: b255dd13059988fddde9ea187d1dd1017c9a5766
-- 
2.43.0

Re: [PATCH 1/1] drm/xe/survivability: broadcast dmesg when engaging survivability

[Raag Jadav]

On Fri, Oct 23, 2026 at 10:36:25AM -0700, Alan Previn wrote:
> Today, when the driver faces issues with early pcode errors
> and attempts to enter survivabilty (when explicitly requested)
> it may either succeed or fail (latter being possible due to
> underlying subsystem blockers). During this flow the driver remains
> loaded and completely silent. No messages indicate that it may need
> or it attempted and succeeded or it attempted and failed, to enter
> survivability mode. This patch adds some awareness in dmesg.

What case are you exactly hitting here? From what I understand both pcode
and survivability failures are logged inside their helpers.

Raag

Re: [PATCH 1/1] drm/xe/survivability: broadcast dmesg when engaging survivability

[Teres Alexis, Alan Previn]

On Wed, 2026-10-28 at 04:18 +0100, Jadav, Raag wrote:
> On Fri, Oct 23, 2026 at 10:36:25AM -0700, Alan Previn wrote:
> > Today, when the driver faces issues with early pcode errors
> > and attempts to enter survivabilty (when explicitly requested)
> > it may either succeed or fail (latter being possible due to
> > underlying subsystem blockers). During this flow the driver remains
> > loaded and completely silent. No messages indicate that it may need
> > or it attempted and succeeded or it attempted and failed, to enter
> > survivability mode. This patch adds some awareness in dmesg.
> 
> What case are you exactly hitting here? From what I understand both pcode
> and survivability failures are logged inside their helpers.
> 
> Raag

I believe the issue couple of us observed was unexpected value in check_boot_failure
called from xe_survivability_mode_is_requested. But as we went back up the stack we
had absolutey zero indication there was any error. nothing indicated we were even
in survivability mode. At least in that failure point case.

I understand we have injected sigid code logging in the various other branches
of downstream logic (from xe_device_probe_early->xe_pcode_probe_early /
xe_survivability_mode_is_requested), however, I it would be more intuitive
to put a single message at that top level to at least indicate some kind of
survivability activity was directed, attempted and entered-or-failed-to-enter

If you believe the correct fix should be to ONLY keep error logs at every
subbranch instead at the top level, thats fine with me too too but i notice
they currently don't actually convey the survivability state.
We have messages like "Firmware flash required" or "Boot mode enabled"
but nothing saying we are in survivability and the gpu isnt usable.

Re: [PATCH 1/1] drm/xe/survivability: broadcast dmesg when engaging survivability

[Raag Jadav]

On Thu, Oct 29, 2026 at 02:31:21AM +0530, Teres Alexis, Alan Previn wrote:
> On Wed, 2026-10-28 at 04:18 +0100, Jadav, Raag wrote:
> > On Fri, Oct 23, 2026 at 10:36:25AM -0700, Alan Previn wrote:
> > > Today, when the driver faces issues with early pcode errors
> > > and attempts to enter survivabilty (when explicitly requested)
> > > it may either succeed or fail (latter being possible due to
> > > underlying subsystem blockers). During this flow the driver remains
> > > loaded and completely silent. No messages indicate that it may need
> > > or it attempted and succeeded or it attempted and failed, to enter
> > > survivability mode. This patch adds some awareness in dmesg.
> > 
> > What case are you exactly hitting here? From what I understand both pcode
> > and survivability failures are logged inside their helpers.
> > 
> > Raag
> 
> I believe the issue couple of us observed was unexpected value in check_boot_failure
> called from xe_survivability_mode_is_requested. But as we went back up the stack we
> had absolutey zero indication there was any error. nothing indicated we were even
> in survivability mode. At least in that failure point case.
> 
> I understand we have injected sigid code logging in the various other branches
> of downstream logic (from xe_device_probe_early->xe_pcode_probe_early /
> xe_survivability_mode_is_requested), however, I it would be more intuitive
> to put a single message at that top level to at least indicate some kind of
> survivability activity was directed, attempted and entered-or-failed-to-enter
> 
> If you believe the correct fix should be to ONLY keep error logs at every
> subbranch instead at the top level, thats fine with me too too but i notice
> they currently don't actually convey the survivability state.
> We have messages like "Firmware flash required" or "Boot mode enabled"
> but nothing saying we are in survivability and the gpu isnt usable.

From what I found both success and fail cases are logged here.

        if (check_boot_failure(xe))
                xe_log_err_fatal(pdev, SURVIVABILITY, 0, "Boot Mode enabled!\n");
        else
                xe_log_info(pdev, SURVIVABILITY, "Boot Mode enabled!\n");

These logs use SURVIVABILITY as a component which would appear in dmesg
(not a fan of it myself, but that's unfortunately the xe_log design).

I do agree that we could log something like "Entering survivability mode"
somewhere if xe_survivability_mode_is_requested() were to return true,
unless Riana has a better idea.

Raag

Re: [PATCH 1/1] drm/xe/survivability: broadcast dmesg when engaging survivability

[Tauro, Riana]

On 29-10-2026 10:18, Raag Jadav wrote:
> On Thu, Oct 29, 2026 at 02:31:21AM +0530, Teres Alexis, Alan Previn wrote:
>> On Wed, 2026-10-28 at 04:18 +0100, Jadav, Raag wrote:
>>> On Fri, Oct 23, 2026 at 10:36:25AM -0700, Alan Previn wrote:
>>>> Today, when the driver faces issues with early pcode errors
>>>> and attempts to enter survivabilty (when explicitly requested)
>>>> it may either succeed or fail (latter being possible due to
>>>> underlying subsystem blockers). During this flow the driver remains
>>>> loaded and completely silent. No messages indicate that it may need
>>>> or it attempted and succeeded or it attempted and failed, to enter
>>>> survivability mode. This patch adds some awareness in dmesg.
>>> What case are you exactly hitting here? From what I understand both pcode
>>> and survivability failures are logged inside their helpers.
>>>
>>> Raag
>> I believe the issue couple of us observed was unexpected value in check_boot_failure
>> called from xe_survivability_mode_is_requested. But as we went back up the stack we
>> had absolutey zero indication there was any error. nothing indicated we were even
>> in survivability mode. At least in that failure point case.
>>
>> I understand we have injected sigid code logging in the various other branches
>> of downstream logic (from xe_device_probe_early->xe_pcode_probe_early /
>> xe_survivability_mode_is_requested), however, I it would be more intuitive
>> to put a single message at that top level to at least indicate some kind of
>> survivability activity was directed, attempted and entered-or-failed-to-enter
>>
>> If you believe the correct fix should be to ONLY keep error logs at every
>> subbranch instead at the top level, thats fine with me too too but i notice
>> they currently don't actually convey the survivability state.
>> We have messages like "Firmware flash required" or "Boot mode enabled"
>> but nothing saying we are in survivability and the gpu isnt usable.
>  From what I found both success and fail cases are logged here.
>
>          if (check_boot_failure(xe))
>                  xe_log_err_fatal(pdev, SURVIVABILITY, 0, "Boot Mode enabled!\n");
>          else
>                  xe_log_info(pdev, SURVIVABILITY, "Boot Mode enabled!\n");
>
> These logs use SURVIVABILITY as a component which would appear in dmesg
> (not a fan of it myself, but that's unfortunately the xe_log design).
>
> I do agree that we could log something like "Entering survivability mode"
> somewhere if xe_survivability_mode_is_requested() were to return true,
> unless Riana has a better idea.


If we are seeing a pcode init failure without boot status failed, then 
that is a issue.
The only other way to enable this is via configfs.

SIGID logs do print survivability

<3>xe 0000:03:00.0: [drm] *ERROR* SIGID=103 FATAL SURVIVABILITY: Boot 
Mode enabled!

Agree with Raag here.  We can remove this log from 
enable_boot_survivability_mode
and add it in is_requested instead.

Thanks
Riana


>
> Raag

Re: [PATCH 1/1] drm/xe/survivability: broadcast dmesg when engaging survivability

[Teres Alexis, Alan Previn]

> > > I believe the issue couple of us observed was unexpected value in check_boot_failure
> > > called from xe_survivability_mode_is_requested. But as we went back up the stack we
> > > had absolutey zero indication there was any error. nothing indicated we were even
> > > in survivability mode. At least in that failure point case.
> > > 
> > > I understand we have injected sigid code logging in the various other branches
> > > of downstream logic (from xe_device_probe_early->xe_pcode_probe_early /
> > > xe_survivability_mode_is_requested), however, I it would be more intuitive
> > > to put a single message at that top level to at least indicate some kind of
> > > survivability activity was directed, attempted and entered-or-failed-to-enter
> > > 
> > > If you believe the correct fix should be to ONLY keep error logs at every
> > > subbranch instead at the top level, thats fine with me too too but i notice
> > > they currently don't actually convey the survivability state.
> > > We have messages like "Firmware flash required" or "Boot mode enabled"
> > > but nothing saying we are in survivability and the gpu isnt usable.
> >  From what I found both success and fail cases are logged here.
> > 
> >          if (check_boot_failure(xe))
> >                  xe_log_err_fatal(pdev, SURVIVABILITY, 0, "Boot Mode enabled!\n");
> >          else
> >                  xe_log_info(pdev, SURVIVABILITY, "Boot Mode enabled!\n");
> > 
> > These logs use SURVIVABILITY as a component which would appear in dmesg
> > (not a fan of it myself, but that's unfortunately the xe_log design).
alan: personal note - i think for these kinds of globally impacting event messages
i think it makes sense to be present dmesg.

> > 
> > I do agree that we could log something like "Entering survivability mode"
> > somewhere if xe_survivability_mode_is_requested() were to return true,
> > unless Riana has a better idea.
> 
> 
> If we are seeing a pcode init failure without boot status failed, then 
> that is a issue.
> The only other way to enable this is via configfs.
> 
> SIGID logs do print survivability
> 
> <3>xe 0000:03:00.0: [drm] *ERROR* SIGID=103 FATAL SURVIVABILITY: Boot 
> Mode enabled!
> 
> Agree with Raag here.  We can remove this log from 
> enable_boot_survivability_mode
> and add it in is_requested instead.
> 
> Thanks
> Riana
> 
> 
> > 
> > Raag


sounds good - will add single xe_log_info  to _is_requested.

Re: [PATCH 1/1] drm/xe/survivability: broadcast dmesg when engaging survivability

[Teres Alexis, Alan Previn]

On Thu, 2026-10-29 at 11:41 -0700, Teres Alexis, Alan Previn wrote:
> > > > 

While i have your time on this area of code i just realized we have a bug
with how we are using udelay within pcode_try_request where the "wait" param
increases exponentially without bounding to (MAX_UDELAY_MS*1000) - which can
cause overflow and potentially not waiting long enough. this should be a fixup
so ill post separately.

[PATCH 1/1] drm/xe/survivability: broadcast dmesg when engaging survivability

[Alan Previn]

When user requests to enter survivabilty via configfs, or if
check_boot_failure is hit inside xe_survivability_mode_is_requested,
no indication is published. This patch adds some awareness in dmesg.

 v3 : Limit message to xe_survivability_mode_is_requested. (Riana)
 v2 : Remove / modify messages to reflect underlying behavior. (Sashiko)

Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com>
---
 drivers/gpu/drm/xe/xe_survivability_mode.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/xe/xe_survivability_mode.c b/drivers/gpu/drm/xe/xe_survivability_mode.c
index d73cdad0b3a9..344b402eb728 100644
--- a/drivers/gpu/drm/xe/xe_survivability_mode.c
+++ b/drivers/gpu/drm/xe/xe_survivability_mode.c
@@ -413,13 +413,19 @@ bool xe_survivability_mode_is_requested(struct xe_device *xe)
 
 	survivability_mode = xe_configfs_get_survivability_mode(pdev);
 	/* Enable survivability mode if set via configfs */
-	if (survivability_mode)
+	if (survivability_mode) {
+		xe_log_info(xe, SURVIVABILITY, "Boot mode requested.");
 		return true;
+	}
 
 	data = xe_mmio_read32(mmio, PCODE_SCRATCH(0));
 	survivability->boot_status = REG_FIELD_GET(BOOT_STATUS, data);
 
-	return check_boot_failure(xe);
+	if (check_boot_failure(xe)) {
+		xe_log_err_fatal(pdev, SURVIVABILITY, 0, "Boot Mode enabled!\n");
+		return true;
+	}
+	return false;
 }
 
 /**

base-commit: d8a353e238652bec29fd452babdaae0044d30b9b
-- 
2.43.0

Re: [PATCH 1/1] drm/xe/survivability: broadcast dmesg when engaging survivability

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] drm/xe: duplicate and false logs in xe_survivability_mode_is_requested()
--

commit ba1b85f1f1a898ddfee38c1e881310a987970b44
Author: Alan Previn <alan.previn.teres.alexis@intel.com>

drm/xe/survivability: broadcast dmesg when engaging survivability

This commit adds kernel log messages to xe_survivability_mode_is_requested()
when boot survivability mode is requested via configfs or when PCODE_SCRATCH(0)
reports a boot failure.

> diff --git a/drivers/gpu/drm/xe/xe_survivability_mode.c b/drivers/gpu/drm/xe/xe_survivability_mode.c
> index 45d44ebe288b4..3eebb69728c3f 100644
> --- a/drivers/gpu/drm/xe/xe_survivability_mode.c
> +++ b/drivers/gpu/drm/xe/xe_survivability_mode.c
> @@ -412,13 +412,19 @@ bool xe_survivability_mode_is_requested(struct xe_device *xe)
>  
>  	survivability_mode = xe_configfs_get_survivability_mode(pdev);
>  	/* Enable survivability mode if set via configfs */
> -	if (survivability_mode)
> +	if (survivability_mode) {
> +		xe_log_info(xe, SURVIVABILITY, "Boot mode requested.");
>  		return true;
> +	}
>  
>  	data = xe_mmio_read32(mmio, PCODE_SCRATCH(0));
>  	survivability->boot_status = REG_FIELD_GET(BOOT_STATUS, data);
>  
> -	return check_boot_failure(xe);
> +	if (check_boot_failure(xe)) {
> +		xe_log_err_fatal(pdev, SURVIVABILITY, 0, "Boot Mode enabled!\n");
> +		return true;
> +	}
> +	return false;
>  }

[Severity: Medium]
Does logging inside xe_survivability_mode_is_requested() cause duplicate and
premature messages in dmesg?

During probe, xe_device_probe_early() calls
xe_survivability_mode_is_requested() in the condition and then calls
xe_survivability_mode_boot_enable(), which calls
xe_survivability_mode_is_requested() a second time:

drivers/gpu/drm/xe/xe_device.c:xe_device_probe_early() {
	...
	err = xe_pcode_probe_early(xe);
	if (err || xe_survivability_mode_is_requested(xe)) {
		int save_err = err;
		...
		err = xe_survivability_mode_boot_enable(xe);
}

drivers/gpu/drm/xe/xe_survivability_mode.c:xe_survivability_mode_boot_enable() {
	...
	if (!xe_survivability_mode_is_requested(xe))
		return 0;
}

When xe_pcode_probe_early() returns 0 (for example, when survivability mode is
enabled via configfs), xe_survivability_mode_is_requested() runs twice back to
back and emits the log message twice. Also, "Boot mode requested." is missing a
trailing newline.

For the check_boot_failure(xe) path, enable_boot_survivability_mode() already
logs the exact same message once boot survivability mode has actually been
initialized:

drivers/gpu/drm/xe/xe_survivability_mode.c:enable_boot_survivability_mode() {
	...
	if (check_boot_failure(xe))
		xe_log_err_fatal(pdev, SURVIVABILITY, 0, "Boot Mode enabled!\n");
	else
		xe_log_info(pdev, SURVIVABILITY, "Boot Mode enabled!\n");

	return 0;

failed:
	xe_log_err_fatal(pdev, SURVIVABILITY, ret, "Failed to enable Boot Mode!\n");
	survivability->mode = false;
	return ret;
}

Logging "Boot Mode enabled!\n" inside xe_survivability_mode_is_requested() not
only duplicates the message in enable_boot_survivability_mode(), but also
reports that boot mode is enabled before initialization has happened. If
xe_survivability_mode_boot_enable() aborts with -ENXIO (when
survivability->version < 2 and boot_status is CRITICAL_FAILURE) or if
enable_boot_survivability_mode() fails in create_survivability_sysfs(),
xe_nvm_init(), or xe_i2c_probe(), dmesg will falsely report "Boot Mode
enabled!" before failing.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261030171738.674775-2-alan.previn.teres.alexis@intel.com?part=1