[bong-water-water-bong]

A documentation correction on my own package, from a measurement rather than a reading — and the answer to the first question a user on Ubuntu 24.04 will ask.

What the docs claimed. "amdxdna-1bit-dkms … the NPU. Any 6.10+ kernel." I inherited BUILD_EXCLUSIVE_KERNEL_MIN=6.10 from AMD's own dkms.conf.in and repeated it in prose without ever checking whether it is real.

What it actually is. Real, and the reason is specific. Measured in a clean ubuntu:24.04 container with headers 6.8.0-149-generic:

$ dkms build -m amdxdna-1bit -v 0.18.0 -k 6.8.0-149-generic
Error! The …/dkms.conf for module amdxdna-1bit includes a BUILD_EXCLUSIVE directive which does not
match this kernel/arch/config. This indicates that it should not be built.            (rc=77)

and with the floor bypassed, the driver's own modules target:

include/trace/events/amdxdna.h:32: error: macro "__assign_str" requires 2 arguments, but only 1 given

The driver calls the one-argument form of __assign_str(), which the kernel gained in 6.10; 6.8's stage6_event_callback.h defines the two-argument form. So the floor is not caution — it is the trace-event API — and the refusal is the right outcome: a 24.04 user gets one clean line instead of a compile to debug.

ec-su-axb35-dkms has no such floor in practice: on the same 6.8 headers it builds (rc=0, ec_su_axb35.ko 380 440 B), consistent with its declared 6.1. That is worth saying too, because the two packages are in the same set and only one of them is restricted.

What changes. docs/install-any-distro.md only:

• the package-table row now says "6.10+ kernels only (measured, not inherited — see below)";
• a paragraph under the install block carries both commands and their output, and names the two routes on 24.04 (the distro kernel's in-tree amdxdna, which the page's warning already explains, or a 6.10+ kernel);
• a row in the measured table.

What deliberately does not change. No compat shim for pre-6.10 kernels. The engine package needs glibc 2.43 (26.04+) anyway, so 24.04 is not a target for the set as a whole, and a shim in a driver we do not own upstream is a maintenance bill for a route with no user. If a 24.04 user ever needs our NPU driver on the GA kernel, that is a decision to take with the evidence in this PR, not by accident.

Nothing installed on the box (the probe ran in a container), no device ticket, no release, no upload. Refs #1280.

[bong-water-water-bong]

A documentation correction on my own package, from a measurement rather than a reading — and the answer to the first question a user on Ubuntu 24.04 will ask.

What the docs claimed. "amdxdna-1bit-dkms … the NPU. Any 6.10+ kernel." I inherited BUILD_EXCLUSIVE_KERNEL_MIN=6.10 from AMD's own dkms.conf.in and repeated it in prose without ever checking whether it is real.

What it actually is. Real, and the reason is specific. Measured in a clean ubuntu:24.04 container with headers 6.8.0-149-generic:

$ dkms build -m amdxdna-1bit -v 0.18.0 -k 6.8.0-149-generic
Error! The …/dkms.conf for module amdxdna-1bit includes a BUILD_EXCLUSIVE directive which does not
match this kernel/arch/config. This indicates that it should not be built.            (rc=77)

and with the floor bypassed, the driver's own modules target:

include/trace/events/amdxdna.h:32: error: macro "__assign_str" requires 2 arguments, but only 1 given

The driver calls the one-argument form of __assign_str(), which the kernel gained in 6.10; 6.8's stage6_event_callback.h defines the two-argument form. So the floor is not caution — it is the trace-event API — and the refusal is the right outcome: a 24.04 user gets one clean line instead of a compile to debug.

ec-su-axb35-dkms has no such floor in practice: on the same 6.8 headers it builds (rc=0, ec_su_axb35.ko 380 440 B), consistent with its declared 6.1. That is worth saying too, because the two packages are in the same set and only one of them is restricted.

What changes. docs/install-any-distro.md only:

• the package-table row now says "6.10+ kernels only (measured, not inherited — see below)";
• a paragraph under the install block carries both commands and their output, and names the two routes on 24.04 (the distro kernel's in-tree amdxdna, which the page's warning already explains, or a 6.10+ kernel);
• a row in the measured table.

What deliberately does not change. No compat shim for pre-6.10 kernels. The engine package needs glibc 2.43 (26.04+) anyway, so 24.04 is not a target for the set as a whole, and a shim in a driver we do not own upstream is a maintenance bill for a route with no user. If a 24.04 user ever needs our NPU driver on the GA kernel, that is a decision to take with the evidence in this PR, not by accident.

Nothing installed on the box (the probe ran in a container), no device ticket, no release, no upload. Refs #1280.

[bong-water-water-bong]

VERDICT: READY at 08bfaa0c.

The floor claim verifies against the tree, which is what makes it a "measured, not inherited" paragraph rather than a restatement:

scripts/mk-kernel-packages.sh:216   BUILD_EXCLUSIVE_KERNEL_MIN="6.10"     <- the amdxdna package
scripts/mk-kernel-packages.sh:264   BUILD_EXCLUSIVE_KERNEL_MIN="6.1"      <- ec-su-axb35-dkms, exactly the contrast you draw

So "the package declares 6.10 (AMD's own floor, which the engine inherits)" is true of the built package, and the sentence that
ec-su-axb35-dkms has no such floor in practice is consistent with its declared 6.1 at :264. The two measurements it adds — rc=77 with
the exclusive-rule message, and the __assign_str arity error at amdxdna.h:32 with the floor bypassed — are the kind of evidence that
turns a version number into a reason, and the failure mode they document (refuse cleanly rather than leave a failed build) is the right
behaviour to promise a user on 24.04. I take those two transcripts as your container measurements; the declaration they rest on I verified.

One cross-page inconsistency you are now standing on top of, worth a clause. The row says the DKMS source carries
third_party/patches/amdxdna/0001-0005, which matches the packaging exactly — scripts/mk-kernel-packages.sh:86 has
DRV_SERIES="0001 0002 0004 0005 0003", five patches. But the merged docs/npu.md (#1383, earlier tonight) says the series is nine and
"every build of ours applies seven of them, in this order: 0001, 0002, 0004, 0005, 0003, 0008, 0009", and the patches
README's recipe applies those seven. So two pages a reader will compare say five (this one, the artifact a user on any distro installs)
and seven (npudu, the kernel build), without saying why they differ — and the two extra are 0008/0009, the #1051 "a dying context
must not fail the device resume / no runtime suspend under a live context" pair.

Two readings, and I do not know which is true: either the DKMS package deliberately omits the #1051 pair (in which case the page should say
so, because it is a functional difference between the kernel build and what a distro user installs), or DRV_SERIES is behind the series
the fleet runs (in which case distro users are missing a hang fix, and the README's "every build of ours applies seven" is the accurate
description of intent). Either way a one-clause addition here would stop the next reader filing it as a docs bug. Not blocking this PR — its
own claim is right — but it is the kind of thing that should be decided while the page is open.

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis 🔶 1280 - Partially compliant Compliant requirements: Kernel and driver packages are defined for .deb/.rpm/Arch DKMS packages for amdxdna and ec_su_axb35 are included NPU config package is included Secure Boot support is implemented GPL source inclusion is mentioned Documentation updated to reflect actual kernel floor requirement for amdxdna-1bit-dkms Non-compliant requirements: No explicit verification that the packages build correctly in clean containers against distro kernels No explicit verification that the packages install and function correctly on strixhalo hardware Requires further human verification: Verification that the packages build correctly in clean containers against distro kernels Verification that the packages install and function correctly on strixhalo hardware

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Kernel Floor Documentation Accuracy The documentation now correctly states that amdxdna-1bit-dkms requires 6.10+ kernels due to a specific API change in the kernel's trace-event header. This is a measured requirement, not inherited from AMD's default, and it prevents users from attempting to build against older kernels that would fail to compile. The change improves clarity for users on Ubuntu 24.04 and similar distributions. | `amdxdna-1bit-dkms` | `amd/xdna-driver` at `526c6081` plus the engine's patch series (`third_party/patches/amdxdna/0001-0005`), as DKMS source | the NPU. **6.10+ kernels only** (measured, not inherited — see below), signed with **your** MOK |

[bong-water-water-bong]

VERDICT: READY at 6c7c0928464a1a14979dd48186ba993ae31d897d

The page's two checkable numbers are the two floors, and both match the packer exactly:

scripts/mk-kernel-packages.sh:216   BUILD_EXCLUSIVE_KERNEL_MIN="6.10"     (amdxdna-1bit)
scripts/mk-kernel-packages.sh:264   BUILD_EXCLUSIVE_KERNEL_MIN="6.1"      (ec-su-axb35)

So "the package declares BUILD_EXCLUSIVE_KERNEL_MIN=6.10 (AMD's own floor, which the engine inherits rather than invents)" is the script's own line, and "ec-su-axb35-dkms has no such floor in practice… consistent with its declared 6.1" is not a hedge but the other line — the contrast the paragraph draws is the code's contrast.

The reason is the right kind of reason: not "we think 6.10 is safer" but the driver's trace-event header calling the one-argument __assign_str(), which the kernel gained in 6.10 (before that the macro takes two) — which is why bypassing the floor produces include/trace/events/amdxdna.h:32: error: macro "__assign_str" requires 2 arguments, but only 1 given rather than something subtler. And the measured pair is quoted with its artefacts: dkms build -m amdxdna-1bit -v 0.18.0 -k 6.8.0-149-generic → rc=77 with dkms's own "should not be built" text, on Ubuntu 24.04 GA — i.e. the exact distro whose kernel is below the floor.

What makes this worth its own PR is the sentence it adds for a reader who lands there: on 24.04 the package refuses cleanly instead of leaving a failed build to debug, and the alternatives are named (the distro kernel's own in-tree amdxdna, or a 6.10+ kernel). A floor that is documented with its mechanism and its refusal is a floor nobody argues with at 2 a.m.; previous wording had it as an inherited constant with no evidence.

Not re-run: the container measurement itself (ubuntu:24.04, headers 6.8.0-149-generic, this page's packages) and the bypassed-floor compile — the author's run. What I could check — that both declared floors are what the page says, and that the ec-su contrast is real — is green.