[Bug][Linux][Share Compute] MeshLLM Vulkan runtime crashes with SIGILL on x86-64 CPUs without AVX
- Dominant language
- Rust
- Stars
- 32.7k
- Forks
- 4.3k
- Avg merge
- 1d 13h
- Merged PRs (30d)
- 253
Description
**Describe the bug**
On Linux, enabling **Share this machine** downloads the selected model and the
MeshLLM Vulkan native runtime, then terminates the entire Buzz desktop process
while initializing the model on an x86-64 CPU without AVX.
The kernel reports an invalid-opcode trap in the embedded MeshLLM thread. The
core dump points to the bundled Vulkan runtime's `libggml-cpu.so`; disassembly
shows that the faulting instruction is the AVX instruction `vmovdqa`. The host
CPU supports SSE4.2 but does not advertise AVX.
This is separate from #3747: that issue concerns an AVX instruction in
JavaScriptCore/WebKit. Here the Buzz UI is initially functional and the crash
occurs in MeshLLM/GGML only after Share Compute starts model initialization.
**Steps to reproduce**
1. On an x86-64 Linux system whose CPU supports SSE4.2 but not AVX, install the
official Buzz 0.5.4 amd64 `.deb`.
2. Open **Settings -> Compute**.
3. Select `gemma-4-E4B-it-Q4_K_M.gguf` from the suggested models.
4. Enable **Share this machine**.
5. Wait for the model and native runtime downloads to finish.
6. Observe that Buzz exits during model initialization.
The model download completed successfully (4,977,171,584 bytes), and MeshLLM
recorded it as first used immediately before the crash. No sharing/model-serving
listener became available.
**Expected behavior**
Buzz/MeshLLM should detect host CPU instruction-set compatibility before
selecting or loading a native runtime. On a CPU that does not meet the runtime's
requirements, it should either select a compatible runtime or display a clear
unsupported-CPU message without terminating Buzz. Ideally, this check should
also occur before downloading a multi-gigabyte model.
**Version and platform**
- Buzz version: 0.5.4, official amd64 `.deb`
- OS: Linux Mint 22.3 (Zena)
- Kernel: 7.0.0-28-generic
- CPU: Intel Core i5-760 @ 2.80 GHz
- Relevant CPU flags: SSE4.1 and SSE4.2 present; AVX absent
- GPU: NVIDIA GeForce GTX 970, 4096 MiB
- NVIDIA driver: 580.173.02
- MeshLLM version: 0.74.0
- Native runtime: `meshllm-native-runtime-linux-x86_64-vulkan`
- Model: `unsloth/gemma-4-E4B-it-GGUF`,
`gemma-4-E4B-it-Q4_K_M.gguf`
**Logs / additional context**
Sanitized kernel/core evidence:
```text
kernel: traps: mesh-llm-embedd[...] trap invalid opcode
ip:... in libggml-cpu.so
Signal: 4 (ILL)
Command Line: /usr/bin/buzz-desktop
Stack trace of the faulting thread:
#0 $HOME/.cache/mesh-llm/native-runtimes/0.74.0/
meshllm-native-runtime-linux-x86_64-vulkan/lib/libggml-cpu.so + 0x1ca05
#1 .../libggml-cpu.so + 0x1da8d
```
Disassembly at the reported offset:
```text
000000000001ca05:
c5 f9 6f 6d b0 vmovdqa -0x50(%rbp),%xmm5
```
There was no OOM kill, GPU reset, thermal event, or machine reboot associated
with the crash. A systemd core dump was captured locally, but it is not attached
because process-memory dumps may contain private Buzz data.
**Documentation/build-pipeline findings**
I checked the current Buzz shared-compute runbook and MeshLLM 0.74.0 native
runtime documentation before filing:
- No documented AVX minimum was found for Linux Share Compute or the Linux
x86-64 Vulkan runtime.
- MeshLLM's native-runtime design says the resolver detects OS, architecture,
GPU devices/drivers, and backend availability. Its documented compatibility
checks cover ABI, OS/architecture/target, CUDA, ROCm, and Vulkan availability,
but do not include x86 CPU instruction features.
- The 0.74.0 runtime build script sets `GGML_NATIVE=OFF`, but does not explicitly
set or record an x86 ISA baseline in the runtime manifest.
- The pinned llama.cpp CMake configuration exposes `GGML_AVX`, `GGML_AVX2`,
`GGML_FMA`, `GGML_F16C`, and `GGML_BMI2` options, so producing a non-AVX
variant appears technically possible. The current published runtime is not
compatible with this non-AVX host.
Relevant sources:
- Buzz shared-compute runbook:
https://github.com/block/buzz/blob/main/docs/buzz-shared-compute-dev.md
- MeshLLM 0.74.0 native-runtime design:
https://github.com/Mesh-LLM/mesh-llm/blob/e60b2fe43aa05271569fbeff2a457133aef456a1/docs/design/NATIVE_RUNTIMES.md
- MeshLLM 0.74.0 native-runtime resolver documentation:
https://github.com/Mesh-LLM/mesh-llm/blob/e60b2fe43aa05271569fbeff2a457133aef456a1/crates/mesh-llm-native-runtime/README.md
- MeshLLM 0.74.0 runtime build script:
https://github.com/Mesh-LLM/mesh-llm/blob/e60b2fe43aa05271569fbeff2a457133aef456a1/scripts/build-llama.sh
- Pinned llama.cpp GGML CMake options:
https://github.com/Mesh-LLM/llama.cpp/blob/c96ffc8697b5b6a90b0115888543d93234bf448d/ggml/CMakeLists.txt
**Questions / requested resolution**
1. Is AVX intended to be the minimum CPU requirement for Linux x86-64 native
runtimes? If so, please document it, encode it in runtime compatibility
metadata, and reject unsupported hosts gracefully before model download.
2. If pre-AVX x86-64 remains supported, could release CI publish a compatible
baseline or CPU-feature-specific runtime variant and have the resolver select
it based on detected host features?
3. In either case, can failure to load the sharing runtime be contained so that
it does not terminate the entire Buzz desktop application?
Related issues: #3747, #3788.
Contributor guide
Assessment
This issue has not been assessed yet.