fleet/ohm: switch bes2600 driver scope to cumulative-c5x-danctnix interim (closes #5 partial migration)

Audit during ohm pkgrel=4 migration found the per-series -danctnix mirrors merged in #17 do NOT apply against the linux-pinetab2 baseline: all 17 of them use DKMS-style root paths (bes2600/foo.c) rather than in-tree staging paths (drivers/staging/bes2600/foo.c), and at least one has a corrupted mixed-prefix header (a/drivers/staging/bes2600/... b/bes2600/...). ka-promote ohm with those includes produced a 172 644-byte cumulative touching 27 file paths, of which 11 are bogus. The hand-curated 0001-bes2600-besser-cumulative-series.patch from the working danctnix-besser-pkgbuild flow on boltzmann (148 149 bytes, 48 in-tree staging files) is what pkgrel=3 actually builds with. Until the per-series mirrors are reconstructed (followup issue to be opened separately), the bes2600 driver scope is satisfied here by staging that hand-curated cumulative as a single-file series-dir patches/driver/bes2600/cumulative-c5x-danctnix/. ohm.yaml drops the broken per-series includes in favour of: - driver/bes2600/cumulative-c5x-danctnix/ - driver/bes2600/scan-filter-5ghz-danctnix/ (closes besser#1) - arch/arm64/xor-neon-ffixed-x18-scs-build-fix-danctnix/ ka-promote ohm now produces a self-consistent 157 446-byte cumulative (148 149 + 7 735 + 1 562 = exact byte arithmetic) with b2sum a807297b25be... which is what the new marfrit-packages/arch/linux-pinetab2-danctnix-besser PKGBUILD pkgrel=4 pins. Also fixes fleet/ohm.yaml YAML parse error: bar5_burn_in had a scalar value followed by a sub-list, which ka-promote (PyYAML) refused to parse. The whole manifest had never parsed cleanly since #18 landed. Refs: #5 (migrate PKGBUILD), #2 (mirror besser series — needs per-series rewrite followup), besser#1 (Patch I).
2026-05-18 16:50:41 +02:00
parent 44c6c3fa4f
commit f203b70f4f
7 changed files with 4629 additions and 32 deletions
@@ -0,0 +1,36 @@
+From: Markus Fritsche <fritsche.markus@gmail.com>
+Date: Mon, 18 May 2026 11:42:00 +0200
+Subject: [PATCH] arm64: xor-neon: restore -ffixed-x18 when SHADOW_CALL_STACK=y
+ (GCC 15+ build fix)
+
+GCC 15.2.1 enforces that -fsanitize=shadow-call-stack requires
+-ffixed-x18 inside arm_neon.h's #pragma GCC target() blocks.  The
+existing CFLAGS_REMOVE_xor-neon.o line strips the kernel-wide
+-ffixed-x18 (it's part of CC_FLAGS_NO_FPU) and CC_FLAGS_FPU does not
+restore it, so xor-neon.c fails to build on stricter GCC versions
+when CONFIG_SHADOW_CALL_STACK=y.
+
+Add an explicit -ffixed-x18 just for this object, gated on the
+SCS config so non-SCS builds are unaffected.
+
+Build environment workaround; not a kernel-runtime bug.
+---
+ arch/arm64/lib/Makefile | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/arch/arm64/lib/Makefile b/arch/arm64/lib/Makefile
+index 1234567..2345678 100644
+--- a/arch/arm64/lib/Makefile
+++ b/arch/arm64/lib/Makefile
+@@ -9,6 +9,10 @@ ifeq ($(CONFIG_KERNEL_MODE_NEON), y)
+ obj-$(CONFIG_XOR_BLOCKS)	+= xor-neon.o
+ CFLAGS_xor-neon.o		+= $(CC_FLAGS_FPU)
+ CFLAGS_REMOVE_xor-neon.o	+= $(CC_FLAGS_NO_FPU)
+# GCC 15+ enforces that -fsanitize=shadow-call-stack requires -ffixed-x18
+# even after a #pragma GCC pop_options inside arm_neon.h.  CC_FLAGS_REMOVE
+# above strips the kernel-wide -ffixed-x18 (part of CC_FLAGS_NO_FPU); add
+# it back here so xor-neon.c still compiles when SHADOW_CALL_STACK=y.
+CFLAGS_xor-neon.o		+= $(if $(CONFIG_SHADOW_CALL_STACK),-ffixed-x18)
+ endif
+ 
+ lib-$(CONFIG_ARCH_HAS_UACCESS_FLUSHCACHE) += uaccess_flushcache.o
@@ -0,0 +1,20 @@
+# xor-neon-ffixed-x18-scs-build-fix-danctnix — GCC 15.2.1 build fix
+
+Restores `-ffixed-x18` for `arch/arm64/lib/xor-neon.c` when
+`CONFIG_SHADOW_CALL_STACK=y`. GCC 15.2.1 enforces that
+`-fsanitize=shadow-call-stack` requires `-ffixed-x18` inside
+arm_neon.h's `#pragma GCC target()` push/pop blocks; CC_FLAGS_REMOVE
+strips the kernel-wide `-ffixed-x18` for xor-neon.o and CC_FLAGS_FPU
+does not restore it.
+
+**Note on current ohm config**: `linux-pinetab2-danctnix-besser`
+config has `# CONFIG_SHADOW_CALL_STACK is not set` as of pkgrel=3,
+which makes this patch a runtime no-op (`$(if $(CONFIG_SHADOW_CALL_STACK),
+-ffixed-x18)` evaluates to nothing). Patch is kept in the manifest as
+belt-and-suspenders for the day SCS gets re-enabled (tracked in
+besser issue for GCC fix monitoring).
+
+See [[reference_arm64_scs_arm_neon_gcc15]] for the full toolchain
+analysis. This patch is the upstream-friendly Makefile fix; the
+config-side `SHADOW_CALL_STACK=n` workaround is the immediate
+runtime mitigation. Both are present in pkgrel=3 for safety.
@@ -0,0 +1,35 @@
+# cumulative-c5x-danctnix — interim single-file cumulative
+
+**Series role**: ohm manifest's bes2600 driver patchset, c5x stack as
+shipped in `linux-pinetab2-danctnix-besser` pkgrel=3 on 2026-05-18.
+
+## Why this is a single .patch and not split per-fix
+
+The 12-ish per-series mirror PR (kernel-agent#17) of the boltzmann-side
+`marfrit/besser` series produced patches with DKMS-style paths
+(`bes2600/*` at root) rather than in-tree staging paths
+(`drivers/staging/bes2600/*`), and at least one entry has corrupted
+mixed-prefix headers (`a/drivers/staging/bes2600/foo.c b/bes2600/foo.c`).
+Those series do NOT apply cleanly to the linux-pinetab2 baseline.
+
+Audit performed 2026-05-18 during ohm migration:
+- ka-promote ohm (using the per-series includes) produces a
+  172 644-byte cumulative touching 27 file paths, of which 11 are
+  bogus DKMS-style or mixed-prefix.
+- The hand-curated `0001-bes2600-besser-cumulative-series.patch` from
+  the working `danctnix-besser-pkgbuild` (boltzmann) is 148 149 bytes
+  touching 48 distinct in-tree staging files — and is what pkgrel=3
+  actually builds with.
+
+This single-file cumulative is staged here so the ohm migration can
+ship through the kernel-agent flow today without first reconstructing
+12 series-dirs. The proper per-series split is tracked separately —
+see kernel-agent issue (TBD) for the rewrite.
+
+## Provenance
+
+- Source file: `boltzmann:~/src/besser/marfrit-besser/danctnix-besser-pkgbuild/kernel/0001-bes2600-besser-cumulative-series.patch`
+- Reflects c5x driver state in `marfrit/bes2600-dkms-mobian` branch as
+  of 2026-05-08, applied against `drivers/staging/bes2600/` in-tree.
+- Series legend (A, B, C v3, F, G, D, E, C2, c5.x, c6.x, c7, H — NOT
+  alphabetical) per the danctnix-besser-pkgbuild changelog comments.
@@ -0,0 +1,168 @@
+From 093a5038b8b68f316d976b7cb69609ca7f24f322 Mon Sep 17 00:00:00 2001
+From: Markus Fritsche <fritsche.markus@gmail.com>
+Date: Mon, 18 May 2026 11:27:40 +0200
+Subject: [PATCH 1/2] bes2600: filter 5 GHz scans at the driver boundary
+ (besser#1)
+
+The BES2600 firmware refuses WSM start-scan for 5 GHz with status 2
+("rejected by policy").  This shows up in dmesg as the recurring
+
+    wsm_generic_confirm failed for request 0x0007.
+    [SCAN] Scan failed (-22).
+
+pattern (besser issue #1, ~14-16/h on ohm/PineTab2 baseline).
+
+Trace shows every reject is the second of a back-to-back pair: mac80211
+splits multi-band hw_scan requests per band when the driver does not
+set IEEE80211_HW_SINGLE_SCAN_ON_ALL_BANDS (we don't), then re-invokes
+drv_hw_scan from __ieee80211_scan_completed for each subsequent band.
+The 2.4 GHz iteration succeeds; the 5 GHz iteration is what the
+firmware rejects.  See ieee80211_prep_hw_scan in net/mac80211/scan.c
+for the loop, and the existing memory reference_bes2600_5ghz_scan_reject
+for the firmware behaviour.
+
+The 056a71a defer-on-reject patch already in this tree handles the
+BT-A2DP-coex branch and the consecutive-reject backoff, but it cannot
+prevent the per-band-loop reject: by the time defer_should_scan is
+consulted, the per-band call is already in flight, and the reject_count
+gets reset on every successful 2.4 GHz scan in between (which is
+~36% of attempts), so the threshold never trips.
+
+The fix: refuse the 5 GHz iteration upfront in bes2600_hw_scan.  The
+2.4 GHz scan still runs normally.  The 5 GHz portion is reported as
+aborted to userspace -- same outcome as today, minus the dmesg storm
+and the wsm_generic_confirm WARN cascade.
+
+5 GHz band registration is intentionally left in place: direct-BSSID
+association to a known 5 GHz AP still works (no scan is needed for
+that path), and a future firmware update that fixes the scan behaviour
+should not be foreclosed by changing band advertisement.
+
+Contract: per include/net/mac80211.h ieee80211_ops.hw_scan, a negative
+return aborts the scan without requiring ieee80211_scan_completed().
+-EOPNOTSUPP is the semantically accurate code (operation is legal,
+driver can't service it on this band today).
+
+Phase 3 evidence:
+- baseline N=3: rate ~14.3-23.6/h converged at 14.3/h (matches OP)
+- back-to-back scan gap: 6/6 rejected pairs <200us, 1/1 successful
+  pair was 114ms (single-band-only, no 5 GHz leg)
+- defer log fires: 0/9 in 30-min window (056a71a structurally bypassed)
+
+Predicted Phase 7 delta: Pattern A 14/h -> 0/h.
+---
+ bes2600/scan.c | 22 ++++++++++++++++++++++
+ 1 file changed, 22 insertions(+)
+
+diff --git a/drivers/staging/bes2600/scan.c b/drivers/staging/bes2600/scan.c
+index fb1d298..a81afb6 100644
+--- a/drivers/staging/bes2600/scan.c
+++ b/drivers/staging/bes2600/scan.c
+@@ -238,6 +238,28 @@ int bes2600_hw_scan(struct ieee80211_hw *hw,
+ 	/* Scan when P2P_GO corrupt firmware MiniAP mode */
+ 	if (priv->join_status == BES2600_JOIN_STATUS_AP)
+ 		return -EOPNOTSUPP;
+
+	/*
+	 * Firmware refuses WSM start-scan for 5 GHz with status 2 ("rejected
+	 * by policy"); see besser issue #1.  mac80211 splits multi-band
+	 * hw_scan requests per-band when the driver does not set
+	 * IEEE80211_HW_SINGLE_SCAN_ON_ALL_BANDS (we don't -- see
+	 * ieee80211_hw_set() calls in bes2600_main.c), so each per-band call
+	 * has req->channels[] from one band only (see ieee80211_prep_hw_scan
+	 * in net/mac80211/scan.c).  Refuse the 5 GHz iteration at the driver
+	 * boundary so userspace gets a clean aborted-scan for that portion
+	 * rather than waiting for the firmware reject to cascade up.  5 GHz
+	 * band registration stays intact so direct-BSSID association to a
+	 * known 5 GHz AP still works (no scan needed for that path).
+	 *
+	 * Contract: per include/net/mac80211.h struct ieee80211_ops.hw_scan
+	 * documentation, a negative return aborts the scan without requiring
+	 * ieee80211_scan_completed().
+	 */
+	if (req->n_channels > 0 &&
+	    req->channels[0]->band == NL80211_BAND_5GHZ)
+		return -EOPNOTSUPP;
+
+ #if 0
+ 	if (work_pending(&priv->offchannel_work) ||
+ 			(hw_priv->roc_if_id != -1)) {
+-- 
+2.54.0
+
+
+From 8cd10f487c8144d462a510812ba0fa717b3e24df Mon Sep 17 00:00:00 2001
+From: Markus Fritsche <fritsche.markus@gmail.com>
+Date: Mon, 18 May 2026 15:56:34 +0200
+Subject: [PATCH 2/2] bes2600: scan-filter-5ghz: allow targeted single-channel
+ scans (besser#1 follow-up)
+
+The original Patch I refused EVERY 5 GHz scan request unconditionally
+(req->n_channels > 0 && band == NL80211_BAND_5GHZ).  This eliminated
+the Pattern A storm but also broke 5 GHz association entirely:
+NM / wpa_supplicant iterates a freq_list when a connection profile
+specifies 802-11-wireless.band=a, issuing per-frequency single-channel
+scans to find the BSS before associating.  Those single-channel scans
+were also refused by our guard, so the BSS was never seen and
+'Wi-Fi network could not be found' was the only outcome.
+
+Tighten the guard: refuse only multi-channel 5 GHz scans (n_channels
+> 1), which is the per-band-sweep pattern mac80211 issues internally
+and the only one that triggers the firmware storm at the per-band
+loop boundary.  Single-channel 5 GHz scans pass through to firmware,
+which generally accepts them -- and when they happen to be rejected,
+the failure is isolated and doesn't cascade.
+
+Verified on ohm with pkgrel=3 (srcversion BEB625FA7443171EA8D55F7):
+  - Pattern A count since boot: 0 (Phase 7 prediction still holds)
+  - iw dev wlan0 scan freq 5180          -> allowed
+  - iw dev wlan0 scan freq 5180 5200 ... -> refused -EOPNOTSUPP
+  - NM 'nmcli connection up' with band=a -> associated to BSSID
+    c0:25:06:e6:5b:33 on 5240 MHz / ch.48 in ~1 second
+  - TX bitrate 150 Mbit/s MCS 7 40MHz short-GI (vs 72.2 Mbit/s
+    HT20 on 2.4 GHz) -- ~2x throughput recovered
+
+The change is a single byte (> 0 -> > 1) plus comment update; the
+test confirmation above is what motivates it.
+
+Refs: besser#1 (closed but tracked for follow-up like this), original
+Patch I sha 093a503.
+---
+ bes2600/scan.c | 16 ++++++++++++----
+ 1 file changed, 12 insertions(+), 4 deletions(-)
+
+diff --git a/drivers/staging/bes2600/scan.c b/drivers/staging/bes2600/scan.c
+index a81afb6..497523b 100644
+--- a/drivers/staging/bes2600/scan.c
+++ b/drivers/staging/bes2600/scan.c
+@@ -248,15 +248,23 @@ int bes2600_hw_scan(struct ieee80211_hw *hw,
+ 	 * has req->channels[] from one band only (see ieee80211_prep_hw_scan
+ 	 * in net/mac80211/scan.c).  Refuse the 5 GHz iteration at the driver
+ 	 * boundary so userspace gets a clean aborted-scan for that portion
+-	 * rather than waiting for the firmware reject to cascade up.  5 GHz
+-	 * band registration stays intact so direct-BSSID association to a
+-	 * known 5 GHz AP still works (no scan needed for that path).
+	 * rather than waiting for the firmware reject to cascade up.
+	 *
+	 * Only the multi-channel case is refused (n_channels > 1): that's
+	 * the per-band-sweep pattern mac80211 issues internally and the
+	 * one that triggers the firmware storm at the per-band loop
+	 * boundary.  Single-channel 5 GHz scans (BSS verification, NM's
+	 * per-freq iteration when 802-11-wireless.band=a is set) pass
+	 * through to firmware, which generally accepts them since the
+	 * storm is the back-to-back per-band issue, not a blanket 5 GHz
+	 * reject.  This preserves 5 GHz association via the
+	 * "wpa_supplicant iterates freq_list per channel" path.
+ 	 *
+ 	 * Contract: per include/net/mac80211.h struct ieee80211_ops.hw_scan
+ 	 * documentation, a negative return aborts the scan without requiring
+ 	 * ieee80211_scan_completed().
+ 	 */
+-	if (req->n_channels > 0 &&
+	if (req->n_channels > 1 &&
+ 	    req->channels[0]->band == NL80211_BAND_5GHZ)
+ 		return -EOPNOTSUPP;
+ 
+-- 
+2.54.0
+
@@ -0,0 +1,19 @@
+# scan-filter-5ghz-danctnix — close besser#1
+
+Refuses multi-channel 5 GHz scan requests at the driver boundary with
+`-EOPNOTSUPP`, eliminating the WSM 0x0007 reject storm. Single-channel
+5 GHz scans still pass through (NM `802-11-wireless.band=a` BSS
+verification path stays functional).
+
+Phase 7 baseline on ohm: Pattern A 14.3/h → 0/h (verified 2026-05-18,
+30 min window). 5 GHz association achieves 150 Mbit/s MCS 7 HT40 SGI vs
+72.2 on 2.4 GHz.
+
+Single combined patch file because the two commits in the source
+(initial filter + `n_channels > 1` refinement) form a 2-commit
+follow-up series and git apply concatenation handles both. Splitting
+into two .patch files would mean a fragile dependency on cross-file
+sequencing inside the same series-dir.
+
+Provenance: closes besser#1. Mirror of source-of-truth in
+`marfrit/bes2600-dkms` branch `bes2600/scan-filter-5ghz`.