Files
besser/notes/observed-bugs.md
test0r e580126d84 Initial: BESser umbrella for BES2600 driver mainlining
Sets up the BES2600 mainlining work tree with:

- README: project overview, hardware target, driver lineage
  (CW1200 -> Bestechnic -> arjan-vlek -> Mobian/danctnix), patch series
  status, repo map, build/deploy workflow.

- patches/: c1 patch generated by git format-patch from
  marfrit/bes2600-dkms branch bes2600/factory-request-firmware
  (checkpatch.pl --no-tree --strict: 0 errors / 0 warnings / 0 checks).

- scripts/: build-bes2600-on-ohm.sh, deploy-c1-to-ohm.sh,
  backup-ohm-kernel.sh - reproducible build + deploy + backup.

- fw-analysis/: per-blob strings.txt + fnnames.txt extracted from the
  4 firmware blobs pulled from ohm 2026-04-21. Source binaries NOT
  committed (Bestechnic-proprietary).

- notes/: observed-bugs.md (4 known bug surfaces with file:line +
  patch-series cross-reference), source-map.md (every public driver
  source variant + their canonical role).

Companion work tree: marfrit/bes2600-dkms (Mobian DKMS fork) at
git.reauktion.de.

Signed-off-by: Markus Fritsche <fritsche.markus@gmail.com>
2026-04-22 10:13:23 +02:00

100 lines
3.4 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Observed BES2600 driver bugs on PineTab2 (ohm)
Compiled from on-device dmesg + Pine64 wiki + community reports. Cross-references the patch series.
## Bug #1 — factory.txt path mismatch + filp_open antipattern (FIXED in c1)
**File**: `bes2600_factory.c:148-170` (read), `:188-200` (create)
**Symptom (pre-fix)**:
```
(NULL device *): read and check /lib/firmware/bes2600_factory.txt error
```
**Root cause**: hardcoded `FACTORY_PATH=/lib/firmware/bes2600_factory.txt` Makefile macro;
real file ships at `/lib/firmware/bes2600/bes2600_factory.txt`. Worse, the read uses
`filp_open` + `kernel_read` directly, bypassing the firmware-class infrastructure.
**Fix**: c1 patch — `request_firmware()` for the read path, repointed Makefile macro
to firmware-class name `bes2600/bes2600_factory.txt`.
## Bug #1.5 — factory.txt parse failure (NEW, c5 to investigate)
**File**: `bes2600_factory.c factory_parse()`
**Symptom (post-c1)**:
```
bes2600_factory.txt parse fail
read and check bes2600/bes2600_factory.txt error
factory cali data get failed.
```
**How discovered**: c1 fix exposed a deeper bug — `factory_parse()` chokes on the data
that `request_firmware()` now successfully returns. The original bug masked this
because the read always failed first.
**Hypotheses**: null-termination assumption mismatch (`request_firmware` doesn't
null-terminate), `FACTORY_MEMBER_NUM=30/31` count discrepancy, kmalloc not
zero-initialized, parser strict on trailing `%%\n` delimiter.
**Status**: investigation pending (task c5). Driver falls back to defaults; WiFi
functional but TX power is uncalibrated (all channels at 0x1400).
## Bug #2 — PM low-power handshake timeout (recurring)
**File**: `bes_pwr.c:470-558``bes2600_pwr_enter_lp_mode()`. Error at line 538.
**Symptom**:
```
bes2600_wlan mmc2:0001:1: bes2600_pwr_enter_lp_mode, wait pm ind timeout
```
Fires every 510s in steady state when associated. Floods dmesg, likely
correlates with bug #3 (SDIO TX stack splat) and bad battery life.
**Root cause**: `wait_for_completion_timeout(&pm_enter_cmpl, 5*HZ)` waits
for firmware to acknowledge a PM mode change; firmware never sends ACK.
Driver proceeds to `bes2600_pwr_device_enter_lp_mode()` regardless.
**Mobian == danctnix**: identical bes_pwr.c (1447 lines, 0-hunk diff). No
upstream fix exists; we'd invent it (gate device-LP entry on completion +
add retry).
**Status**: task c2.
## Bug #3 — SDIO TX scatter-gather panic / WARN
**File**: `bes2600_sdio.c:952-1200``bes_sdio_memcpy_to_io_helper`,
`sdio_tx_work`.
**Symptom**:
```
[RX] Receive failure: 4.
bes_sdio_memcpy_to_io_helper+0x18c/0x288 [bes2600]
sdio_tx_work+0x2b4/0x4a0 [bes2600]
Workqueue: bes_sdio sdio_tx_work [bes2600]
```
Recurring under TX load. Can wedge the chip irrecoverably (per Pine64 wiki:
"Power/reset circuitry not properly implemented; hard reset impossible
without board power-cycle").
**Status**: task c3 (indirectly, via bes_chardev removal which currently
gates the signal/nosignal mode switch path).
## Bug #4 — scan_complete_cb constant loop
**File**: `scan.c:883-909``bes2600_scan_complete_cb()`.
**Symptom**:
```
ieee80211 phy0: bes2600_scan_complete_cb status: 0
```
Fires every 210s (status=0 = success, but the FREQUENCY suggests background
scanning runs continuously when associated + idle).
Most likely a NetworkManager scheduling artifact, not a driver bug. Low
priority; suppress the wiphy_dbg print or skip scan-on-assoc'd if it
matters.