Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[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

Abierto
  • ¿Algo no está bien?
#705 3 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
linux
Área
ai-infra-agents, operating-systems

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
C++
Estrellas
2k
Forks
161
Merge medio
2 d 18 h
PR fusionados (30 d)
16

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de ROCm/FastFlowLM

Todos los issues de ROCm/FastFlowLM

Issues similares

Más issues de C++

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.