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.
