You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
ERT_CMD_STATE_ERROR on Strix Halo with firmware 1.1.2.65 #103
Describe the Issue
We are experiencing an ERT_CMD_STATE_ERROR (specifically: aie2_send_mgmt_msg_wait: command opcode failed, status 0x4000003, followed by aie2_hwctx_start: Map host buffer failed, ret -22) when attempting to execute operations on the Strix Halo NPU.
Question
Is firmware version 1.1.2.65 known to have compatibility issues with current IRON deployments? What specific firmware version is recommended/needed for Strix Halo platforms to resolve this mapping buffer failure?
1.1.2.65 firmware user here - works fine for me for IRON. Kernel 6.19.11-gentoo-dist, Strix, XRT master build (~2.23.0), with master xdna-driver (driver + shim + firmware).
Regarding diagnosis, I highly recommend to run and add xrt-smi validate (not just xrt-smi examine) command to README (similar to what we see in flm guide, even though they have their own validator). It is pointless to expect IRON to work if XRT infra setup is not complete.
Regarding combinations of working setups:
All-master setup usually works (unless there is some transition which you can observe in recent commits, i. e. temporary breakage). Don't forget to reload the driver!
Last time I checked, IRON had issues with in-source driver, but I guess that's a common knowledge.
XRT 2.21.75 + shim from XRT 2.21.75 + xdna-driver from 2.21.75 tag works.
But apparently that's not how it was intended by xdna-driver developers - looks like the driver should be taken from 1.7 branch, not 2.21.75 tag. But anyways, now it works.
flm has slightly better "validation":
Checks kernel version and requires kernel 6.17+ or 7.x+.
Iterates over /dev/accel/accel0 through /dev/accel/accel15. For each device found:
Queries the DRM version - requires amdxdna version >= 0.6.
Queries the NPU firmware version - requires firmware >= 1.1.x.
Check the NPUs has at least 8 columns (Phoenix and Hawk Point will fail)
If the memlock limit is below 100 MB, it attempts to auto-raise it to infinity via setrlimit. If that fails, it reports an error.
Agreed with @AngryLoki, if xrt-smi validate does not work this is IRON-unrelated. To test if this is a memory limit issue, try running as superuser (sudo) or raise the limit using ulimit.
Activity
AngryLoki commentedon Apr 17, 2026
1.1.2.65 firmware user here - works fine for me for IRON. Kernel 6.19.11-gentoo-dist, Strix, XRT master build (~2.23.0), with master xdna-driver (driver + shim + firmware).
Regarding diagnosis, I highly recommend to run and add
xrt-smi validate(not justxrt-smi examine) command to README (similar to what we see in flm guide, even though they have their own validator). It is pointless to expect IRON to work if XRT infra setup is not complete.Regarding combinations of working setups:
flm has slightly better "validation":
/dev/accel/accel0through/dev/accel/accel15. For each device found:amdxdnaversion >= 0.6.setrlimit. If that fails, it reports an error.andrej commentedon Apr 17, 2026
Agreed with @AngryLoki, if
xrt-smi validatedoes not work this is IRON-unrelated. To test if this is a memory limit issue, try running as superuser (sudo) or raise the limit usingulimit.The CI runners currently have XDNA at commit
beb9e450fe123ecdf395453971576179cedcf1dd(and the corresponding firmware and XRT submodule) installed, so this is a known-good version.