From 4c80458d1f3dc7b8248183b556deef0534fad050 Mon Sep 17 00:00:00 2001 From: Markus Fritsche Date: Mon, 18 May 2026 15:25:37 +0200 Subject: [PATCH] fleet/ohm: import Patch I (5GHz scan filter) + arm64 SCS build-fix MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Patch I closes besser#1 — the wsm_generic_confirm 0x0007 dmesg storm. One-line guard in bes2600_hw_scan() refuses the 5 GHz iteration of mac80211's per-band hw_scan loop with -EOPNOTSUPP, so the firmware never sees the scan request that would be rejected with status 2 → -EINVAL cascade. Phase 7 verified 2026-05-18 on ohm running pkgrel=2: Pattern A 14.3/h → 0/h over 30-min window, no WARN/BUG, single-band 2.4 GHz scans still return BSSes cleanly. Two flavors imported (scan-filter-5ghz and scan-filter-5ghz-danctnix) matching the convention of other bes2600 series — the code path doesn't touch timer APIs so the two are byte-identical for now; flavor separation is kept to preserve consistency in ohm.yaml. The arm64 scs-arm-neon-build-fix series is a build-environment workaround: GCC 15.2.1 strictly validates that -fsanitize=shadow- call-stack requires -ffixed-x18, and arm_neon.h's #pragma target/ push/pop blocks lose x18 fixing inside the wrapped section. The Makefile tweak re-adds -ffixed-x18 explicitly for xor-neon.o. It's a no-op when SCS is off (current pkgrel=2 ohm config) and unblocks SCS=y once GCC upstream is fixed. ohm.yaml gains a CONFIG_SHADOW_CALL_STACK=n config override with a pointer to besser#20 (the re-enable tracking issue) so future manifest-driven kconfig generation honors the workaround without silently dropping it. Source-of-truth commit for Patch I: marfrit/bes2600-dkms branch bes2600/scan-filter-5ghz sha 093a503 PKGBUILD-side (already deployed to ohm via pkgrel=2): marfrit/besser branch claude-noether-14 sha ae175f9 Refs: besser#1 (closed), besser#20, kernel-agent#5 --- fleet/ohm.yaml | 18 ++++ ...-arm64-xor-neon-ffixed-x18-build-fix.patch | 36 ++++++++ ...r-5-GHz-scans-at-the-driver-boundary.patch | 91 +++++++++++++++++++ ...r-5-GHz-scans-at-the-driver-boundary.patch | 91 +++++++++++++++++++ 4 files changed, 236 insertions(+) create mode 100644 patches/arch/arm64/scs-arm-neon-build-fix/0001-arm64-xor-neon-ffixed-x18-build-fix.patch create mode 100644 patches/driver/bes2600/scan-filter-5ghz-danctnix/0001-bes2600-filter-5-GHz-scans-at-the-driver-boundary.patch create mode 100644 patches/driver/bes2600/scan-filter-5ghz/0001-bes2600-filter-5-GHz-scans-at-the-driver-boundary.patch diff --git a/fleet/ohm.yaml b/fleet/ohm.yaml index efd2003..1bbcff4 100644 --- a/fleet/ohm.yaml +++ b/fleet/ohm.yaml @@ -55,6 +55,18 @@ includes: - driver/bes2600/drop-orphan-file-io-danctnix/ - driver/bes2600/remove-chardev-user-interface/ - driver/bes2600/enable-testmode/ + # Patch I — besser#1 closure. Filter 5 GHz scan iteration at the + # driver boundary (refuses 5 GHz drv_hw_scan with -EOPNOTSUPP). + # Eliminates the wsm_generic_confirm 0x0007 dmesg storm. + # Phase 7 verified 2026-05-18: Pattern A 14.3/h → 0/h. + - driver/bes2600/scan-filter-5ghz-danctnix/ + + # Build-environment workaround for GCC 15.2.1 + CONFIG_SHADOW_CALL_STACK=y + # + arm_neon.h #pragma pop_options interaction. See besser#20 for the + # re-enable-once-GCC-fixed tracking; for now we ship with SCS=n in the + # config and this Makefile tweak as belt-and-suspenders (no-op if SCS + # is off; allows SCS=on once GCC permits). Cross-arch fix, not bes2600. + - arch/arm64/scs-arm-neon-build-fix/ # Explicitly NOT included (decision logged): # - debian-copyright-fsf-address: Debian packaging metadata, not kernel @@ -64,6 +76,12 @@ config: source: hand-managed config file in boltzmann:~/src/besser/marfrit-besser/danctnix-besser-pkgbuild/kernel/config strategy: snapshot, fold to baseline, accept-new with rationale on diff TODO: migrate config into kernel-agent flow once kconfig-by-manifest lands + # Override applied for pkgrel=2 (2026-05-18): CONFIG_SHADOW_CALL_STACK=n + # to work around GCC 15.2.1 arm_neon.h pragma issue. Track besser#20 + # for re-enable plan. Flip back to =y in the manifest once verified + # to build clean on current Arch ARM GCC. + overrides: + CONFIG_SHADOW_CALL_STACK: n # WORKAROUND besser#20 — restore to y when GCC is fixed package: name: linux-pinetab2-danctnix-besser diff --git a/patches/arch/arm64/scs-arm-neon-build-fix/0001-arm64-xor-neon-ffixed-x18-build-fix.patch b/patches/arch/arm64/scs-arm-neon-build-fix/0001-arm64-xor-neon-ffixed-x18-build-fix.patch new file mode 100644 index 0000000..a264806 --- /dev/null +++ b/patches/arch/arm64/scs-arm-neon-build-fix/0001-arm64-xor-neon-ffixed-x18-build-fix.patch @@ -0,0 +1,36 @@ +From: Markus Fritsche +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 diff --git a/patches/driver/bes2600/scan-filter-5ghz-danctnix/0001-bes2600-filter-5-GHz-scans-at-the-driver-boundary.patch b/patches/driver/bes2600/scan-filter-5ghz-danctnix/0001-bes2600-filter-5-GHz-scans-at-the-driver-boundary.patch new file mode 100644 index 0000000..4447378 --- /dev/null +++ b/patches/driver/bes2600/scan-filter-5ghz-danctnix/0001-bes2600-filter-5-GHz-scans-at-the-driver-boundary.patch @@ -0,0 +1,91 @@ +From 093a5038b8b68f316d976b7cb69609ca7f24f322 Mon Sep 17 00:00:00 2001 +From: Markus Fritsche +Date: Mon, 18 May 2026 11:27:40 +0200 +Subject: [PATCH] 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 + diff --git a/patches/driver/bes2600/scan-filter-5ghz/0001-bes2600-filter-5-GHz-scans-at-the-driver-boundary.patch b/patches/driver/bes2600/scan-filter-5ghz/0001-bes2600-filter-5-GHz-scans-at-the-driver-boundary.patch new file mode 100644 index 0000000..4447378 --- /dev/null +++ b/patches/driver/bes2600/scan-filter-5ghz/0001-bes2600-filter-5-GHz-scans-at-the-driver-boundary.patch @@ -0,0 +1,91 @@ +From 093a5038b8b68f316d976b7cb69609ca7f24f322 Mon Sep 17 00:00:00 2001 +From: Markus Fritsche +Date: Mon, 18 May 2026 11:27:40 +0200 +Subject: [PATCH] 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 + -- 2.47.3