Linux on Strix Halo: qwen3.5:9b fails with ERT_CMD_STATE_ABORT, gpt-oss:20b reaches prefill then crashes

Summary

I am testing FastFlowLM on a GMKtec EVO-X2 with AMD Ryzen AI Max+ 395 (Strix Halo / XDNA2) on Ubuntu
24.04.4.

The Linux NPU stack is partially visible, but real model execution is still failing:

• qwen3.5:9b loads and then fails with:
  • Insertion error: runlist failed execution (ERT_CMD_STATE_ABORT)
• gpt-oss:20b now loads, begins prefill, and then crashes:
  • Prefill chunk 1/1 with 68 tokens
  • process exits with core dump / exit 139

Environment

• Hardware: GMKtec EVO-X2
• APU: AMD Ryzen AI Max+ 395
• OS: Ubuntu 24.04.4 LTS
• Kernel: 6.18.10-061810-generic
• FastFlowLM version: 0.9.40
• NPU device: /dev/accel/accel0
• NPU detected as: RyzenAI-npu5
• Current NPU firmware: 1.0.0.166
• amdxdna version reported by flm validate: 0.1
• Memlock: infinity

flm validate

[Linux]  Kernel: 6.18.10-061810-generic
[ERROR]  NPU firmware version on /dev/accel/accel0 is incompatible. Please update NPU firmware!
[ERROR]  amdxdna version 0.1 is incompatible
[Linux]  NPU: /dev/accel/accel0 with 8 columns
[Linux]  NPU FW Version: 1.0.0.166
[Linux]  Memlock Limit: infinity

What I already tried

- Installed XRT userspace (libxrt2, libxrt-npu2, etc.)
- Confirmed /dev/accel/accel0 exists
- Confirmed xrt-smi detects the NPU
- Raised memlock to infinity
- Upgraded FLM from 0.9.39 to 0.9.40
- Tried larger staged models on external storage and also FLM-managed local cache
- Tried the current Linux NPU flow documented by FastFlowLM

Repro 1: qwen3.5:9b

Command:

sudo env HOME=/home/david bash -lc 'ulimit -l unlimited && printf "hello\n" | timeout 45 /usr/bin/flm run 
qwen3.5:9b'

Observed result:

[FLM]  Loading model: /home/david/.config/flm/models/Qwen3.5-9B-NPU2
[FLM]  Loading model: qwen3.5:9b
[FLM]  Type /? for help
>>> hello

[ERROR]  Insertion error: runlist failed execution (ERT_CMD_STATE_ABORT)

Repro 2: gpt-oss:20b

I initially found that an older staged Hugging Face snapshot was treated as an older local model format. After
letting FLM pull a compatible local cache, I retried with:

sudo env HOME=/home/david bash -lc 'ulimit -l unlimited && printf "hello\n" | timeout 60 /usr/bin/flm run 
gpt-oss:20b'

Observed result:

[FLM]  Loading model: /home/david/.config/flm/models/GPT-OSS-20B-NPU2
[FLM]  Loading model: gpt-oss:20b
[FLM]  Type /? for help
>>> hello

[FLM]  Prefill chunk 1/1 with 68 tokens
timeout: the monitored command dumped core

Additional note

Before the compatible local pull, FLM reported:

Local model version: 0.9.17 < 0.9.20
Model is not compatible with the current FLM version.

That part is now worked around locally, but the runtime still fails.

Expected behavior

- If the current firmware/driver combination is unsupported, I would expect a clearer early failure path before
model launch.
- If the stack is expected to work, both models should run without ERT_CMD_STATE_ABORT or core dump.

Questions

1. Is firmware 1.0.0.166 + amdxdna
 0.1 known to be unsupported for Linux FLM on Strix Halo?
2. Is there a recommended firmware / kernel / amdxdna / XRT combination for Ubuntu
 24.04.4 on Ryzen AI Max+ 395?
3. Is the gpt-oss:20b prefill crash a known issue on Linux or specifically on Strix Halo?
4. Is the old-model-format behavior for staged HF snapshots expected for gpt-oss:20b in FLM
 0.9.40?

If helpful, I can provide

- full flm validate output
- xrt-smi output
- exact local model directory contents
- additional logs from retesting under Linux

Start with the flm validate output and reproduce both commands for qwen3.5:9b and gpt-oss:20b on the listed firmware, kernel, amdxdna, and XRT setup. Done means determining whether this combination is supported, identifying the cause of the runtime failures, or documenting an early compatibility error path and the recommended stack.