[BUG] `ras::enumRasErrorSets` returns SUCCESS when the device exposes no RAS domains, so "nothing was measured" is printed as zeros

[AlexanderScha]

Repo: intel/xpumanager · Version: v2.1.0 (tag 6468cecb), defect still present in
current main (hal/core/ras.cpp unchanged as of 06.09.2026)
Package as installed: xpu-smi 2.1.0+26.33.6468cec-1~26.04.
Hardware: 8 × Intel Arc Pro B60 (8086:e211, BMG G21), Linux 7.0.0-31, xe, L0 1.32.0.

Note on scope. An earlier draft of this report also covered the missing
COMPUTE_ERRORS category and the doubling of non-cache counters. Both were fixed
upstream by f43c27c2 ("ras: Consolidate RAS into ras.cpp and match sysman exp
categories") — categories now number ten and the correctable/uncorrectable split comes
from the RAS error set type. Only the defect below remains.

Summary

When a device exposes no RAS domains, enumeration prints an error and then returns
ZE_RESULT_SUCCESS. The caller proceeds, iterates over zero handles, and stats -r prints
a full table of zeros — so "this device reports no RAS data at all" is indistinguishable
from "this device has recorded zero errors".

We hit this as users: we read a table of zeros and concluded our cards had logged no errors
in their lifetime. That conclusion was wrong.

The defect

// hal/core/ras.cpp:35-41
ze_result_t ras::enumRasErrorSets(zes_device_handle_t device)
{
	ze_result_t result = zesDeviceEnumRasErrorSets(device, &rasCount, nullptr);
	if (result != ZE_RESULT_SUCCESS || rasCount == 0) {
		ERR("Failed to enumerate RAS error sets. 0x{:X} ({})\n", result, l0_error_to_string(result));
		return result;
	}

If the driver succeeds but reports zero domains, result is ZE_RESULT_SUCCESS — the
function logs an error and returns success. The message goes to the error log
(suppressed in normal CLI output), so nothing reaches the user.

Called from ras::init() (hal/core/ras.cpp:399), which is invoked during device
initialisation (hal/core/device.cpp:851).

Downstream, getErrorsPerTile loops for (i = 0; i < rasCount; ++i) with rasCount == 0,
touches nothing, returns ZE_RESULT_SUCCESS with the counter still at its initial 0, and
cmd_stats marks the entry valid and prints zeros.

On our hardware

All eight B60 chips expose zero RAS domains — confirmed independently with a small Level
Zero program (zesDeviceEnumRasErrorSets → SUCCESS, count = 0 on every device, both as
root and as an ordinary user). So the true state is "no RAS reporting available", and the
tool renders it as "zero errors recorded".

Suggested fix

Return a distinct status (e.g. ZE_RESULT_ERROR_UNSUPPORTED_FEATURE) when rasCount == 0,
and have stats print N/A rather than 0 for categories that were never sampled.

The distinction matters most exactly when it is needed: on hardware where RAS reporting is
unavailable, the current output actively reassures the user.