pkgrel=5 = pkgrel=4 + besser#18 lockdep fix. Cumulative b2sum
0eb091ddaba4a8f1c3c2a78... (162 704 B, 4 patches). pkgrel=4 kept
in the history table as a migration-only fallback.
- Top-level README: add kernel-agent + marfrit-packages repos to the
Repos table; mark this hand-managed pkgbuild dir as historical.
- danctnix-besser-pkgbuild/README: add a "MOVED" banner pointing at
marfrit/marfrit-packages/arch/linux-pinetab2-danctnix-besser/ as the
canonical PKGBUILD home from pkgrel=4 onwards. Refresh the TL;DR
table (pkgrel=4, new cumulative b2sum bd42cd39..., new "Patch
manifest" row). Add a pkgrel history table. Update Building
section with the kernel-agent flow (and keep the hand-managed flow
as DEPRECATED for reference). Update Installing + Verifying
examples to pkgrel=4. Update Maintenance plan.
Refs: kernel-agent#28, marfrit-packages#28, kernel-agent#29 (per-series
reconstruction follow-up).
| **Module srcversion** | `BEB625FA7443171EA8D55F7` for pkgrel=4 (byte-identical to pkgrel=3 source). pkgrel=5 srcversion differs because the besser#18 fix is bundled (TBD pending build verification). |
| **Kernel base** | DanctNIX [`linux-pinetab2`](https://codeberg.org/DanctNIX/linux-pinetab2) tag `v7.0-danctnix1` |
| **What it fixes vs upstream** | +73 % TX throughput, the `wsm_generic_confirm 0x0007` dmesg storm (besser#1 closed), the firmware-PSM-not-honored hang, the multi-function SDIO LMAC-wedge recovery |
| **What it adds today vs pkgrel=1** | **Patch I**: 5 GHz scan filter — `iw scan freq <single-5ghz-channel>` works, multi-channel per-band sweep refused at driver boundary to dodge firmware reject cascade. NM `band=a` profiles associate to 5 GHz cleanly. **Sustained 11.32 MB/s** download (2.54 GB factory image) on `newton` 5 GHz ch.48 — **3.6× the 2.4 GHz baseline of 3.12 MB/s** on the same source. |
| **Source-of-truth** | `git.reauktion.de/marfrit/bes2600-dkms` — branch `cleanups` for c-stack+A+B, branch `bes2600/scan-filter-5ghz` for Patch I |
| **Source-of-truth (driver)** | `git.reauktion.de/marfrit/bes2600-dkms` — branch `cleanups` for c-stack+A+B, branch `bes2600/scan-filter-5ghz` for Patch I |
| **Caveat** | `CONFIG_SHADOW_CALL_STACK=n` (security-hardening regression, workaround for a GCC 15.2.1 + arm_neon.h pragma issue — tracked in [besser#20](https://git.reauktion.de/marfrit/besser/issues/20), restore to `=y` when GCC is fixed) |
## pkgrel history
| pkgrel | Date | Flow | Notes |
|---|---|---|---|
| 1–3 | 2026-05-08…05-18 | hand-managed, this dir | c-stack + Patches A/B/C/D/E/F/G/H + Patch I + SCS Makefile workaround |
@@ -49,13 +75,35 @@ Individual commits with full rationale + Phase-7 verification logs live on the *
- **Phase 7 (Patch C v3 + F + G + D + E + C2 + H, Mobian-flavor):** N=3 stress @ 4 MB/s sender on RK3566/PineTab2 — Patch B baseline 1.36 MB/s → +73 % sustained 2.28 MB/s. Race-fix verified under stress (no `wsm_release_tx_buffer` WARN storm under load).
- Module loads + associates cleanly; `pm_unsupported` latch fires on boot as expected.
## Building
## Building (pkgrel=4+, kernel-agent flow)
Builds run out of the new home:
```sh
cd ~/src/marfrit-packages/arch/linux-pinetab2-danctnix-besser
makepkg -s
```
Identical workflow to upstream `linux-pinetab2`. Produces `linux-pinetab2-danctnix-besser-<ver>-aarch64.pkg.tar.zst` plus a matching `-headers` package. Build host can be aarch64 native (recommended — no cross-toolchain setup) or x86 with an aarch64 cross-compiler.
To refresh the cumulative patch from a new kernel-agent manifest state:
b2sum 0001-bes2600-besser-kernel-agent-cumulative.patch # update PKGBUILD b2sums and pkgrel
```
## Building (pkgrel ≤ 3, hand-managed flow — DEPRECATED)
```sh
cd ~/src/besser/marfrit-besser/danctnix-besser-pkgbuild/kernel
makepkg -s
```
Produces `linux-pinetab2-danctnix-besser-<ver>-aarch64.pkg.tar.zst` plus a matching `-headers` package. Build host can be aarch64 native (recommended — no cross-toolchain setup) or x86 with an aarch64 cross-compiler.
Build time: ~45–55 min on an 8-core aarch64 host (boltzmann/RPi5-class), most of it the kernel modules phase.
@@ -66,7 +114,7 @@ Build time: ~45–55 min on an 8-core aarch64 host (boltzmann/RPi5-class), most
The package declares `provides=("linux-pinetab2=$pkgver-$pkgrel")` and `conflicts=(linux-pinetab2)`, so `pacman` will cleanly take over from upstream `linux-pinetab2`:
That removes the upstream `linux-pinetab2` package (if installed) and registers the BESser-flavored kernel under the same provides slot. Headers package is optional; install it if you build out-of-tree modules.
@@ -102,7 +150,7 @@ lsmod | grep -i bes2600
# expected: bes2600 (loaded), bes2600_btuart (loaded if Bluetooth in use)
cat /sys/module/bes2600/srcversion
# expected: BEB625FA7443171EA8D55F7 for pkgrel=3
# expected: BEB625FA7443171EA8D55F7 for pkgrel=3 (and pkgrel=4 — byte-identical source)
```
`dmesg | grep bes2600` should show clean firmware load, no SDIO TX panic, no `wsm_release_tx_buffer` WARN storm under load, no `wsm_generic_confirm failed for request 0x0007` storm.
@@ -153,8 +201,10 @@ Drop-in compatibility: same kernel version, same module names, no userspace ABI
## Maintenance plan
- New danctnix kernel release → rebase BESserpatches onto the new tag, regenerate cumulative diff, bump pkgver.
- New BESser patch on Mobian DKMS → re-overlay + re-flavor + regenerate cumulative diff.
**Effective pkgrel=4+:** the per-host manifest in `marfrit/kernel-agent` (`fleet/ohm.yaml`) is the per-patch authority. `ka-promote ohm` produces the cumulative; the PKGBUILD in `marfrit/marfrit-packages` consumes it. Updates flow:
- New danctnix kernel release → bump `baseline.ref` in `fleet/ohm.yaml`, re-promote, bump pkgver in marfrit-packages PKGBUILD.
- New BESser patch → add a new series-dir in `kernel-agent/patches/driver/bes2600/`, add to `fleet/ohm.yaml``includes:`, re-promote, refresh cumulative + b2sum in marfrit-packages PKGBUILD, bump pkgrel.
- Both flavors continue to be maintained in lockstep via `marfrit/bes2600-dkms` source-of-truth.
- GCC 15 SCS issue → periodically re-test build with `CONFIG_SHADOW_CALL_STACK=y` against current Arch ARM GCC. When the build succeeds, flip the config and re-deploy.
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
marfrit
claude-noether