ROCm/HIP: SIGSEGV in rms_norm_mul_f32_cuda on RDNA3 (gfx1101, RX 7800 XT) during Bonsai 27B warmup

[bobNapple]

Summary

llama-server (prebuilt ROCm binary) segfaults during the warmup forward pass on an AMD RDNA3 GPU (gfx1101, RX 7800 XT), inside the custom fused RMS-norm kernel. Reproducible every time, with Ternary-Bonsai-27B-Q2_0.gguf (checksum-verified against the published SHA256).

Environment

• Binary: llama-prism-b9599-9ca265a-bin-ubuntu-rocm-7.2-x64.tar.gz (release prism-b9599-9ca265a, 2026-08-01)
• GPU: AMD Radeon RX 7800 XT (gfx1101), also tested with an RX 6600 XT (gfx1032) present in the same system
• ROCm: 7.2.0 (rocm-core 7.2.0.70200-43~24.04, matches the binary's stated ROCm 7.2 target)
• OS: Ubuntu 24.04 (noble)
• Model: prism-ml/Ternary-Bonsai-27B-gguf — Ternary-Bonsai-27B-Q2_0.gguf (SHA256 verified to match the published hash exactly, not a corrupted download)

Steps to reproduce

LD_LIBRARY_PATH=. ./llama-server \
  -m Ternary-Bonsai-27B-Q2_0.gguf \
  -ngl 999 --port 8199 --host 127.0.0.1

Device enumeration succeeds cleanly (both GPUs detected correctly, e.g. ROCm1: AMD Radeon RX 7800 XT (16368 MiB, 16146 MiB free)), the model loads, and it crashes during the warmup empty-run forward pass with SIGSEGV.

Backtrace (gdb)

Thread 1 "llama-server" received signal SIGSEGV, Segmentation fault.
0x00007fffc5eb0c8f in ?? () from /opt/rocm-7.2.0/lib/libamdhip64.so.7
#0  0x00007fffc5eb0c8f in ?? () from /opt/rocm-7.2.0/lib/libamdhip64.so.7
#1  0x00007fffc5eb14e4 in ?? () from /opt/rocm-7.2.0/lib/libamdhip64.so.7
#2  0x00007fffc5f07185 in ?? () from /opt/rocm-7.2.0/lib/libamdhip64.so.7
#3  0x00007fffc5eb204e in ?? () from /opt/rocm-7.2.0/lib/libamdhip64.so.7
#4  0x00007fffc5ec9efe in ?? () from /opt/rocm-7.2.0/lib/libamdhip64.so.7
#5  0x00007fffef6fa2ba in rms_norm_mul_f32_cuda(float const*, float const*, float const*, float*, int, int, int, int, long, long, long, long, long, long, unsigned int, unsigned int, unsigned int, unsigned int, long, long, long, unsigned int, unsigned int, unsigned int, unsigned int, float, ihipStream_t*) () from libggml-hip.so
#6  0x00007fffef6f8e07 in ggml_cuda_op_rms_norm_fused(ggml_backend_cuda_context&, ggml_tensor*, ggml_tensor*) () from libggml-hip.so
#7  0x00007fffef5d8d77 in ggml_cuda_graph_evaluate_and_capture(ggml_backend_cuda_context*, ggml_cgraph*, bool, bool, void const*) () from libggml-hip.so
#8  0x00007fffef5d39a6 in ggml_backend_cuda_graph_compute(ggml_backend*, ggml_cgraph*) () from libggml-hip.so
#9  0x00007ffff6f701ff in ggml_backend_sched_graph_compute_async () from libggml-base.so.0
#10 0x00007ffff62db721 in llama_context::graph_compute(ggml_cgraph*, bool) () from libllama.so.0
#11 0x00007ffff62dbb2b in llama_context::process_ubatch(...) () from libllama.so.0
#12 0x00007ffff62e5b8a in llama_context::decode(llama_batch const&) () from libllama.so.0
#13 0x00007ffff62e74c0 in llama_decode () from libllama.so.0
#14 0x00007ffff680de84 in common_init_from_params(common_params&, bool) () from libllama-common.so.0
#15 0x00007ffff75745d4 in server_context_impl::load_model(common_params&) () from libllama-server-impl.so
#16 0x00007ffff74c318a in llama_server(int, char**) () from libllama-server-impl.so

The fault address itself is inside libamdhip64.so.7 (stripped, no symbols) — 4 frames deep from the entry into rms_norm_mul_f32_cuda, so I can't tell from this alone whether the bug is in the kernel's own GPU-side code or in how it invokes the HIP runtime, but it's consistently reproducible at this exact call chain.

What I tried

• GGML_CUDA_DISABLE_GRAPHS=1 and GGML_CUDA_DISABLE_FUSION=1 (both present in the binary per strings) — crash persists at the same point, so it doesn't appear to be specifically the graph-capture/kernel-fusion optimization path.
• Tested Ternary-Bonsai-27B-Q2_g64.gguf instead (mainline-packed group-64 format) — fails to load in this binary with a GGUF structural error (expected, per the Bonsai-demo repo's own compat table: g64 is mainline-only, not the fork).
• Confirmed the Q2_0.gguf file itself is not corrupted (SHA256 matches HuggingFace's published hash exactly).
• Ruled out a build regression: downloaded and tested the older prebuilt release prism-b9591-62061f9-bin-ubuntu-rocm-7.2-x64.tar.gz — the same commit that PrismML-Eng/Bonsai-demo#92 reports working on this exact GPU (gfx1101, RX 7800 XT). Identical segfault, same backtrace, on that build too.
• Ruled out multi-GPU device splitting: this system also has an RX 6600 XT (gfx1032). Pinned the model to only the 7800 XT via -dev ROCm1 (device identity cross-checked against lspci/rocm-smi/rocminfo PCI bus IDs to be certain, in case of an enumeration-order mismatch across boots) — same crash.

Given #92 reports this exact commit working on the same GPU, the two things I haven't been able to test/rule out are: ROCm version (I'm on 7.2.0, #92's working report was ROCm 7.1) and prebuilt-binary-vs-self-built-from-source (I've only tested the prebuilt releases). If either of those turns out to matter, that'd be useful to know for anyone else hitting this on a prebuilt ROCm 7.2 binary. Happy to provide more diagnostics (full verbose HIP logs, rocminfo output, etc.) if useful.