Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[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

Open
  • Is something wrong?
#705 3 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 5 days

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Bug
Clarity
Needs clarification
Activity status
Active
Tech stack
linux
Domain
ai-infra-agents, operating-systems

Research direction

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.

Written by the indexing model from the issue text.

Description

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

   
Hardware Framework Desktop, AMD Ryzen AI MAX+ 395 (Strix Halo, gfx1151)
FLM v1.0.4
NPU /dev/accel/accel0, 8 columns
NPU firmware 1.1.2.65
amdxdna 0.7 (in-tree, Proxmox kernel 7.0.14-12-pve)
Memlock infinity
Host Proxmox VE 9.2.10; FLM runs in an unprivileged LXC with /dev/accel/accel0 passed through
Server flags flm serve --port 52625 --host :: --quiet --asr 1 --embed 1 --socket 30 --q-len 20 qwen3-it:4b

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
rocminfo --support output 
Paste output here
Additional Information

No response

Dominant language
C++
Stars
1.9k
Forks
156
Avg merge
5d 2h
Merged PRs (30d)
12

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ROCm/FastFlowLM

All issues in ROCm/FastFlowLM

Similar issues

More C++ issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.