[Issue]: Qwen3.5 / Qwen3.6 family fails to load on Strix Halo (Ryzen AI MAX+ 395, NPU2) — CREATE_HWCTX err=-22, while all other models work

Start by reproducing the Qwen3.5 load failure with flm validate and the reported model command, then inspect aie2_ctx.c and aie2_alloc_resource around CREATE_HWCTX. Compare the failing hybrid-attention models with the listed working models and review the related regression reports. Done means identifying whether Strix Halo support or a version fix is required; the issue does not name a patch or test target.

Problem Description

On a Strix Halo system every model of the Qwen3.5 / Qwen3.6 generation fails to load with a hardware-context allocation error, while every other model in the registry loads and runs fine on the same machine, same FLM version, same session.

The failure is independent of model size (a 4B fails exactly like a 35B), independent of NPU occupancy, and unaffected by a clean re-download of the weights.

Environment

flm validate is fully green:

[Linux]  NPU: /dev/accel/accel0 with 8 columns
[Linux]  NPU FW Version: 1.1.2.65
[Linux]  amdxdna version: 0.7
[Linux]  Memlock Limit: infinity

Failing models

• qwen3.5:4b
• qwen3.6-moe:35b-a3b

Working models on the very same system

gpt-oss:20b, qwen3-it:4b, qwen3vl-it:4b, qwen2.5vl-it:3b, medgemma:4b, translategemma:4b, whisper-v3:turbo, embed-gemma:300m

Error

From FLM:

[FLM]  Loading model: /root/.config/flm/models/Qwen3.5-4B-NPU2
[ERROR]  Failed to load model: DRM_IOCTL_AMDXDNA_CREATE_HWCTX IOCTL failed (err=-22): Invalid argument

From the host kernel log at the same instant:

amdxdna 0000:c3:00.1: [drm] *ERROR* aie2_send_mgmt_msg_wait: command opcode 0x2 failed, status 0x2000003
amdxdna 0000:c3:00.1: [drm] *ERROR* aie2_hwctx_init: Alloc hw resource failed, ret -22
amdxdna 0000:c3:00.1: [drm] *ERROR* amdxdna_drm_create_hwctx_ioctl: Init hwctx failed, ret -22

The rejection comes from the firmware, not from the driver's size check

aie2_ctx.c has its own guard that fires when a context asks for more columns than the device has:

hwctx->num_col = hwctx->num_tiles / row_count;
if (!hwctx->num_col || hwctx->num_col > ndev->total_col) {
        XDNA_ERR(xdna, "Invalid num_col %d", hwctx->num_col);
        return -EINVAL;
}

That message never appears. The requested geometry fits within the 8 columns; the failure happens later, inside aie2_alloc_resource(), where the NPU firmware answers status 0x2000003.

What I ruled out

Model size — qwen3.5:4b fails identically to qwen3.6-moe:35b-a3b. A 4B model is not large by any measure here; gpt-oss:20b loads fine.

NPU occupancy / column contention — qwen3.5:4b fails even when the NPU holds only one small model. Conversely medgemma:4b loads successfully immediately after gpt-oss:20b had been resident. So it is not a matter of free columns.

Stale weights — the v1.0.3 release notes mention the Q4_1 → Q4_K requantization and a required re-download, so I did a full flm remove qwen3.5:4b followed by flm pull qwen3.5:4b. All 6 files freshly downloaded, All files verified successfully. The model still fails with the same error.

What the failing models have in common

Both are the Qwen3.5/3.6 hybrid linear-attention architecture. From Qwen3.5-4B-NPU2/config.json:

"head_dim": 256,
"attn_output_gate": true,
"full_attention_interval": 4,
"layer_types": ["linear_attention", "linear_attention", "linear_attention", "full_attention", ...]

Every model that works on this machine uses conventional attention.

Possibly related

• #501 — request to publish official .q4nx for Qwen3.6-35B-A3B, no maintainer reply.
• #547 — a user asks for "compatible XDNA2 / NPU2 xclbins" for their specific part, which suggests the per-model NPU binaries are built per NPU variant.
• The published Qwen3.6 benchmarks were measured on Ryzen AI 7 350 (Kraken Point); Strix Halo / Ryzen AI MAX 395 is not listed.
• A NixOS Discourse thread reports the identical CREATE_HWCTX err=-22 for qwen3.5:2b on Ryzen AI 350, described upstream as a regression in newer FLM releases and worked around by reverting to 0.9.44.

Questions

1. Are the Qwen3.5 / Qwen3.6 NPU kernels expected to work on Strix Halo (Ryzen AI MAX+ 395), or are they currently built only for Kraken Point / Strix Point?
2. If this is the regression referenced above, is a fix planned for the 1.0.x line, or is 0.9.44 the only version where these models load?

Minor, separate issue found while debugging

flm pull <model> --force does not re-download. It checks only for file presence and reports No files to download for model: .... This matters because the auto-pull triggered by the first request fetches only missing files, which can leave a model directory mixing formats across versions — in my case model.q4nx and config.json from today alongside tokenizer.json and vision_weight.q4nx from April. The only reliable way to refresh is flm remove followed by flm pull.

Operating System

Proxmox VE 9.2.10 (Debian 13), kernel 7.0.14-12-pve. FLM runs inside an unprivileged LXC (Debian 13 trixie) with /dev/accel/accel0 passed through.

CPU

AMD RYZEN AI MAX+ 395 w/ Radeon 8060S (Strix Halo), Framework Desktop

GPU

Integrated Radeon 8060S (gfx1151) [1002:1586]. NPU: Strix Halo Neural Processing Unit [1022:17f0] rev 11, /dev/accel/accel0, 8 columns, firmware 1.1.2.65, amdxdna 0.7 (in-tree).

ROCm Version

FastFlowLM v1.0.4. No separate ROCm runtime is installed in this container — this is the NPU-only path.

ROCm Component

No response

Steps to Reproduce

No response

(Optional for Linux users) Output of /opt/rocm/bin/rocminfo --support

Paste output here

Additional Information

No response