Repository navigation
Bump HRX: llama.cpp e7e5cd08f9bb + hrx-system 82804197bcbe - #565
Merged
Merged
Conversation
PR Reviewer Guide 🔍(Review updated until commit 4d79ec5)Here are some key observations to aid the review process:
|
This was referenced Oct 25, 2026
bong-water-water-bong
enabled auto-merge (squash)
October 25, 2026 12:57
|
Persistent review updated to latest commit 3a919a8 |
|
Persistent review updated to latest commit 4d79ec5 |
This was referenced Oct 25, 2026
bong-water-water-bong
added a commit
that referenced
this pull request
Oct 26, 2026
…hat server for Lemonade (#580) * os: write the onebit manifest the check reads, report skip reasons honestly Three defects a hardware run of candidate 5 exposed, all in the image's own tooling rather than in the release itself. 1. `/etc/1bit/onebit-models.txt` had no producer. release-check.sh read it and, when it was absent, failed with "the build writes it from server_models.json" - but nothing in the tree ever wrote it, so the `models` row could never pass on any image. mkimage.sh now derives it from the Lemonade catalogue it already stages at /opt/lemonade/bin/resources/server_models.json, in the format release-check parses: `mode=<live|installed>` then one `hrx <id>` / `npu <id>` per entry. Deriving it means it cannot drift from what Lemonade actually ships; a catalogue with no onebit entries writes a manifest with none, which the check reports as such instead of failing. The JSON walk accepts both a list of model dicts and a dict of sections, so a layout change produces a manifest rather than silently producing an empty one. 2. The `chat-hrx` and `chat-npu` skips blamed the environment for what is often a missing entry. Both now distinguish the two cases: no /dev/kfd (or /dev/accel/accel*) means the machine cannot run the entry, while a present device with no matching model id means Lemonade listed nothing to ask. On the hardware run this mattered: the row said "no AMD GPU in this VM" on a machine with a GPU. 3. The `secureboot` row skipped whenever mokutil was absent, though mokutil is not shipped - so a machine that had Secure Boot ON and had just booted our MOK-signed kernel was reported as unknown. It now reads the firmware's own SecureBoot EFI variable (byte 5 of SecureBoot-8be4df61-...), which needs no extra binary: 1 passes "Secure Boot enabled; the MOK-signed kernel booted", 0 passes on a firmware that reports it off, and only an unreadable variable stays a skip. self-test passes (7/7 verdict cases). Apache-2.0 headers untouched. * os: ship the HSA runtime beside the engine's llama-server, and name that server for Lemonade First hardware boot of the signed image (candidate 5, 26 Oct, Secure Boot on): 14 of 16 release checks pass, and the two onebit rows fail for reasons the VM gate cannot see. 1. Lemonade's HRX recipe starts the engine through scripts/lemonade-hrx, whose default llama-server is the one beside the script (hrx/llama/bin/llama-server). The image keeps it at /opt/1bit-llama, so lemond logged "Failed to execute: hrx/llama/bin/llama-server" and the model never started. init.sh now exports ONEBIT_HRX_LLAMA_SERVER=/opt/1bit-llama/llama-server (the script's override), for lemond and for ssh logins through /etc/profile. 2. With the server named, llama-server listed no HRX0 at all: libggml-hrx is dlopened by ggml and NEEDS libhsa-runtime64.so.1, which was not beside it - the stage only resolved the program's own NEEDED entries. The only way to load it on the stick was Lemonade's bundle on LD_LIBRARY_PATH, which then mixed that bundle's libloomc into the engine (undefined symbol loomc_link_index_builder_allocate). mkimage.sh now resolves the NEEDED entries of every lib*.so in /data/1bit-llama as well, copies the HSA runtime's ROCm sysdeps flat beside it (relocate() makes every file look in $ORIGIN only), and refuses the build if any library still misses one. /etc/1bit/libhsa prefers that copy; Lemonade's bundle stays as the fallback for older data partitions. Not fixed here: the engine's own default llama-server path when run by hand (follow-up issue), and the image's engine package itself, which candidate 4 and 5 inherited from candidate 3 (package-only runs) and which predates the HRX_ALLOW_NO_SVM gate (#565); candidate 6 is a full build. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> --------- Co-authored-by: bong-water-water-bong <bong-water-water-bong@1bit.gg> Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Moves the HRX submodules along our line. AMD's tested pair (ROCm/ggml-staging-automation) is llama.cpp
1ec5a7a69da5+ hrx-system5f4dfc8731a1; the workflow merges it into our branches (a conflict fails the run and names the files).851fa6c8d8f2e7e5cd08f9bb82804197bcbe82804197bcbehrx-system HELD at
82804197bcbebyconfig/hrx-system-hold.config(AMD's tested pin is5f4dfc8731a1).llama.cpp commits new to the engine:
e7e5cd08fqwen4exp: route IQ2_S routed experts to HRX when the HIP add-on exports the kernels (actions: bump actions/deploy-pages from 4.0.5 to 5.0.1 #144)9705173c0dflash: apply the target's prism.hadamard folds to the shared token table and lm_head (workflows: pin actions by commit SHA; Dependabot keeps the pins current #143)a25b4b835qwen4exp: Qwen3.8-Flash-Next on HRX (IMROPE->NEOX rope, HRX rms_norm view inputs, routed experts deferred to the HIP add-on; IQ2_S stays on CPU) (Security policy, and RFCs in Discussions for changes that shape the engine #142)d65a7e57aggml-hrx: FILL constant in the program-cache key; DFlash2 TOP_K cases in test-backend-ops (HRX: decode_split_next_q8 gives wrong, nondeterministic attention at short context (up to 3.66 nats between identical requests) #140)e91b608cdspec: DFlash2 block drafters on the pinned branch (local conv as strided views, GDN verify snapshots in fused chunks) (serve --mmproj (images in chat); Zyphra Zamba2-VL on Vulkan (pin llama.cpp-vulkan 2c9d3983) #139)f08bd76f6jinja: accept \xNN escapes in the lexer (weekly: run Lemonade's suite against a running lemond; clearer held reasons #135)c3eef46c0models: add Flint (FlintForCausalLM), ported from upstream #30928 (weekly: force the checkout of main in the workspace #134)830e2c161tests: fix test-hrx-ops from the first device run (engine HRX: hrx-backend-test and test-hrx-ops abort on stale kernel-routing expectations #444) (Bump ZINC: zolotukhin/zinc 29bc350ac4cb #132)f1670b43chrx: the absent bias/residual slots of mul_mat_id_postops bind a read-only value (engine hrx-backend-test: two fused plans fail the command-program verifier (transient read before write) #533 verify) (docs: ZAYA1-base and ZAYA1-reasoning-base checked; the ZAYA multi-sequence fix #131)8509e42c3tests: re-read the open rows at the current pin (engine hrx-backend-test: 49 host cases red after the AMD-core re-head — classification (stale expectation vs needs a ruling) #445, fork 7ca8ba5a) (Pin llama.cpp 706ad1a: ZAYA with several sequences per ubatch #130)7ca8ba5a4tests: follow the pin's routes and report verifier failures (engine hrx-backend-test: 49 host cases red after the AMD-core re-head — classification (stale expectation vs needs a ruling) #445) (ZAYA1 legacy checkpoints and remote chat templates: pin llama.cpp 567d2dc; ZAYA1-74B docs #129)6e57798e5tests: name the kquant decode route for the few-token matmuls in test-hrx-ops (engine HRX: hrx-backend-test and test-hrx-ops abort on stale kernel-routing expectations #444, item 2) (tools/gguf_to_q4nx.py: repack a GGUF into a Q4NX model directory #128)5fd1d30faggml-hrx: fix the PAD param dump so the tree compiles, and run test-hrx-ops case by case (engine HRX: hrx-backend-test and test-hrx-ops abort on stale kernel-routing expectations #444) (Pin llama.cpp 4380daf: ZAYA1-74B (sliding-window layers) on Vulkan #127)9b846c173tests: assert the publication this line makes, not the fused producers f2099e9b removed (engine HRX: restore consumer-driven activation publication (dropped whole in f2099e9b) #449) (site: meta descriptions and titles sized for search results #126)CI here builds without HRX. Before merging, on Strix Halo run the long-prompt correctness
probe and
test-backend-ops -b HRX0; record the exact validated hrx-system pin inconfig/hrx-long-prompt-validated-pin.config:python3 tests/hrx_long_prompt.pycmake -B build -G Ninja -DONEBIT_HRX=ON && cmake --build build --target onebit && for d in hrx cpu; do tests/serve_e2e.sh build/1bit <Qwen3-0.6B Q4_K_M .gguf> $d; done