Even more counters in Sysman are broken on Arc Alchemist

[ProjectPhysX]

Pre-submission Checklist

• I am using the latest GPU driver version (releases)
• I have searched for similar issues and found none

GPU Hardware

Intel Arc A750

DRI Devices Information

GPU Detailed Information (lspci output)

Driver Version

26.05.37020.3

Installed GPU Driver Packages

No response

Driver Installation Details

Followed installation instructions from here: https://github.com/intel/compute-runtime/releases/tag/26.14.37833.4

Linux Distribution

Ubuntu 24.04 LTS

Other Linux Distribution

No response

Kernel Version & Boot Parameters

kernel 6.17.0-22-generic

Actual Behavior

Issue moved from oneapi-src/level-zero#440

Plugging in my trusty Intel Arc A750 for more testing, I found many more broken Sysman counters specifically for Arc Alchemist GPUs, additionally to the broken counters reported in oneapi-src/level-zero#434:

counter on Arc A750	Windows	Linux
zes_mem_bandwidth_t::maxBandwidth	❌ wrongly reports max bandwidth in bits/s, not bytes/s	❌ returns 0
zes_mem_bandwidth_t::readCounter/writeCounter/timestamp	✅ works	❌ always return 0
zesDeviceEnumTemperatureSensors()	✅ works	❌ zesDeviceEnumTemperatureSensors() function returns ZE_RESULT_SUCCESS but returns 0 zes_temp_handle_t's
zesTemperatureGetState()	⚠ works, but suffers with frequent value dropouts to 0	❔ cannot test because no zes_temp_handle_t's
zes_fan_handle_t	✅ works	❌ broken (no fans available)
ZES_FREQ_DOMAIN_MEMORY	✅ available	❌ unavailable
zes_freq_state_t::actual for ZES_FREQ_DOMAIN_MEMORY	❌ returns frequency in MT/s, not MHz (a factor 8 too large for GDDR6)	❌ unavailable
zesDeviceGetCardPowerDomain()	❌ returns ZE_RESULT_ERROR_UNSUPPORTED_FEATURE, workaround with zesDeviceEnumPowerDomains() required	❌ returns ZE_RESULT_ERROR_UNSUPPORTED_FEATURE, workaround with zesDeviceEnumPowerDomains() required
zes_pci_stats_t::txCounter/rxCounter/timestamp	❌ return 0	❌ return 0

For Arc Alchemist on Windows, at least no administrator permissions are required.

Expected Behavior

All Sysman counters should work and none of them should require sudo / administrator permissions.

Reproduction Rate

Always reproduces - 100%

Steps to Reproduce

For debugging you may use https://github.com/ProjectPhysX/hw-smi

Is this a regression?

• Yes, this is a regression - functionality that previously worked is now broken

Last Known Working Driver Version

No response

First Known Failing Driver Version

No response

API Call Logs

No response

strace Logs

No response

System Logs / dmesg Output

No response

Backtrace (if crash or hang occurred)

No response

Source Code / Reproducer

No response

Command Line / Application Details

No response

oneAPI Version (if applicable)

No response

Screenshots / Video

No response

Additional Notes

No response

[eero-t]

Note that things may not broken in compute-runtime driver itself, because counter availability does not depend only on the (compute-runtime) user-space driver, but also on the hardware, firmware and given kernel driver version supporting it, and them matching.

(While ABI disconnect issues between different compute-runtime & kernel versions are very rare, I've seen kernel updates break things twice in ~5 years.)

kernel 6.17.0-22-generic

With the i915 kernel driver? Which firmware version(s)?

For Arc Alchemist on Windows, at least no administrator permissions are required.

On Linux side, kernel requires process to have extra privileges to access the metrics data, see e.g: https://github.com/intel/xpumanager/tree/v2.x/xpumd#metrics

• I am using the latest GPU driver version (releases)[x] I have searched for similar issues and found none
  ...
  Intel Arc A750
  ...
  26.05.37020.3

That is not the latest released driver, 26.14.37833.4 is.

(As Arc has been out for a while, newer driver is unlikely to have significant impact, but may still be good to check if you have time.)

[SilentSobs]

Great insights @eero-t, thank you. I've traced through the compute-runtime source to understand the enumeration path and can confirm your findings about the dependencies.

Code Path Analysis

The critical chain for zesDeviceEnumTemperatureSensors on Linux is:
zesDeviceEnumTemperatureSensors
→ TemperatureHandleContext::init() [sysman_temperature.cpp:29]
→ OsTemperature::getSupportedSensors() [sysman_os_temperature_imp.cpp:161]
→ SysmanProductHelper::getSupportedSensors() → populates sensor type map
→ TemperatureImp::init() [sysman_temperature_imp.cpp:30]
→ isTempModuleSupported() [sysman_os_temperature_imp.cpp:103]
→ PlatformMonitoringTech::isTelemetrySupportAvailable() [sysman_pmt.cpp:152]

The PMT telemetry check must pass for temperature sensors to enumerate. It requires:

1. /sys/class/intel_pmt/telem* nodes present
2. Telemetry GUID matching one in the product's guidToKeyOffsetMap
3. /telem device file accessible

For Arc Alchemist (DG2), supported GUIDs are: 0x4f95 (DG2 basic), 0x4f9301 (ATSM), 0x4f9302 (ATS-M1), 0x4f9502 (ATS-M3) from guidToKeyOffsetMap. A different GUID would silently block telemetry.

Diagnostic Request

@ProjectPhysX Could you run these to help narrow down the issue?

1. Which kernel driver is active?

lsmod | grep -E "i915|xe"
# Fallback if built-in (not a module):
cat /sys/module/i915/version 2>/dev/null
cat /sys/module/xe/version 2>/dev/null

The i915 driver returns an empty string for getTemperatureMaxFileName() (upstream), disabling hwmon temperature max. The xe driver returns "temp2_max" (source).

2. Is the PMT module loaded?

lsmod | grep intel_pmt

Without intel_pmt, isTelemetrySupportAvailable() returns false for all sensors.

3. Are PMT telemetry nodes present?

ls -la /sys/class/intel_pmt/
cat /sys/class/intel_pmt/telem*/guid 2>/dev/null
ls -la /sys/class/intel_pmt/telem*/telem 2>/dev/null

The code checks for the /telem device entry at sysman_pmt.cpp:170. If the GUID doesn't match the supported list or the telem file is missing, telemetry fails.

4. Firmware version:

dmesg | grep -E "i915|xe" | grep -i firmware

5. Driver version:
You're on 26.05.37020.3, but 26.14.37833.4 is the latest. Worth testing if PMT-related fixes landed.

6. If on i915, test with xe:

modinfo xe  # check availability

Booting with xe.force_probe=<PCI-ID> (or blacklisting i915) would isolate whether this is KMD-specific.

Happy to continue once we have these results!