[widgetii]

Problem

#2455: a GK7205V210 camera with an AltoBeam ATBM6012B USB adapter and mem=32M loses memory while it streams RTMP over Wi-Fi. No /proc/meminfo field accounts for it, and the camera ends in OOM and watchdog resets. Over Ethernet it doesn't happen, and rmmod of the driver gives the memory back.

The root cause has two parts:

• An application leaves received TCP data unread. majestic's outgoing RTMP connection didn't read what the server sent back (acknowledgements, pings) before master+88fb005, so each small reply stayed queued on the socket.
• The AltoBeam drivers make each queued reply cost a whole 32 KiB block. atbm_get_skb() copies every received frame with dev_alloc_skb(), which carves it out of an order-3 (32 KiB) page-frag block. One frame left queued keeps the whole block alive, but the socket is charged only the frame's truesize, a few hundred bytes. So rcvbuf and tcp_mem never limit it, and nothing in /proc/meminfo shows it.

This PR fixes the driver half: received frames are copied with alloc_skb() (kmalloc), so a queued frame costs what it is charged, shows up in Slab, and the socket limits hold.

Package	Change
atbm-wifi	Fetched from OpenIPC's fork of gtxaspec/atbm-wifi, pinned at 5a0a920 instead of HEAD: the fix (OpenIPC/atbm-wifi#1), plus a Makefile that builds on 4.9 kernels under GNU make 4.4 (the upstream one stops with Makefile.lib:402: prerequisites cannot be defined in recipes). Config.in names the URL.
atbm60xx, atbm603x-comb-openipc	OpenIPC/atbm_60xx 70d6dec (OpenIPC/atbm_60xx#8): the same fix, in the root drop and in atbm603x_comb/.

Hardware tested on

Not run on a camera with an AltoBeam adapter. The evidence is a reproduction in qemu-bench. It uses the emulated ATBM6012B (007a:888b, AresLite) on the gk7205v200 and gk7201v200 machines, which have a USB host since OpenIPC/qemu-bench#238. The test is an upload over Wi-Fi only, with no Ethernet, that never reads the 16-byte replies its server sends every 64 KiB.

Evidence

Reporter's configuration (gk7205v210 kernel, atbm6012b_wifi_usb from atbm-wifi, mem=32M), 3 minutes:

	stock driver	this change
OOM	within 30 s (upd invoked oom-killer)	none
Memory in no /proc/meminfo field	+10 MiB (about 16 MiB at the OOM)	+256 KiB, flat
TCP: mem (pages)	about 51	115, flat
Slab		+356 KiB, flat
Live page-frag blocks under the ATBM RX path	pinning	0

gk7201v200, atbm603x_comb_wifi_usb as #2729 ships it: stock 6 OOM kills, upload dead at 63 MB. This change: no OOM, 1.36 GB sent, TCP: mem 123 pages and flat, Slab +328 KiB and flat.

With no replies, neither build drains. The reporter's own log shows TCP: mem 116 during the drain, the same plateau the fixed build settles at.

Builds: gk7201v200_lite from this branch (firmware.bin: uImage 1837K + squashfs 5352K = 7232K of 7616K). No in-tree defconfig selects atbm-wifi (only builder profiles do), so CI never builds it. I built it locally on gk7205v210_lite, selecting it in that build only: it fetched openipc/atbm-wifi at 5a0a920, applied 0001-casting.patch, and atbm6012b_wifi_usb.ko built under make 4.4.1. The image then overflowed the fixed rootfs slot by 364 KB, which comes from adding a 900 KB driver to that image and not from this change. With SOURCE_DATE_EPOCH and ATBM_BUILD_TIME pinned, atbm-wifi's Makefile change gives a byte-identical module under make 4.3 before and after.

Scope

• No kernel patches under general/package/all-patches/linux/ (those go to OpenIPC/linux)
• No files specific to a single retail camera model (those go to OpenIPC/builder)
• No probing or bring-up tooling (that goes to OpenIPC/ipctool)
• Nothing under general/overlay/ or in a shared load_<vendor> script hardcodes a value specific to my board
• Package sources come from an OpenIPC repository, and any version bump keeps at least the specificity of the pin it replaces (a new package should pin a full 40-character SHA)
• No LD_PRELOAD, and no binaries that cannot be rebuilt from source
• New code is selected by a defconfig, so CI actually builds it

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Pin AltoBeam drivers with the RX buffer allocation fix

🐞 Bug fix ⚙️ Configuration changes 🕐 20-40 Minutes

AI Description

• Pin atbm-wifi to OpenIPC's fork for the RX fix and GNU make 4.4 compatibility.
• Advance both atbm_60xx packages to a revision that prevents unread replies from pinning 32 KiB
 blocks.
• Document the atbm-wifi source repository.

Diagram

graph TD
  W["atbm-wifi recipe"] --> F["OpenIPC atbm-wifi"] --> R["RX skb copies"] --> Q["TCP receive queue"]
  S["atbm60xx recipe"] --> U["OpenIPC atbm_60xx"] --> R
  C["atbm603x-comb recipe"] --> U

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Carry local driver patches

• ➕ Keeps the existing upstream source selection.
• ➖ Duplicates downstream maintenance across driver variants.
• ➖ Requires carrying the make compatibility fix locally as well.

Recommendation: Prefer the pinned OpenIPC revisions: they provide the RX fix across all three packages while keeping the selected source reproducible. Local patches would add maintenance without a clear benefit.

Files changed (4) +8 / -4

Documentation (1) +2 / -0

Config.inDocument the atbm-wifi source +2/-0

Document the atbm-wifi source

• Adds the OpenIPC fork URL to the package help text so its source is visible in configuration.

general/package/atbm-wifi/Config.in

Other (3) +6 / -4

atbm-wifi.mkPin atbm-wifi to the fixed OpenIPC fork +4/-2

Pin atbm-wifi to the fixed OpenIPC fork

• Replaces the unpinned gtxaspec HEAD source with a full-SHA OpenIPC fork revision. That source carries the RX allocation fix and GNU make 4.4 compatibility fix.

general/package/atbm-wifi/atbm-wifi.mk

atbm603x-comb-openipc.mkAdvance the combined driver source revision +1/-1

Advance the combined driver source revision

• Pins the combined driver package to the OpenIPC atbm_60xx revision containing the RX allocation fix.

general/package/atbm603x-comb-openipc/atbm603x-comb-openipc.mk

atbm60xx.mkAdvance the atbm60xx driver source revision +1/-1

Advance the atbm60xx driver source revision

• Updates the pinned OpenIPC atbm_60xx revision to include the RX allocation fix while retaining the previously pinned make compatibility change.

general/package/atbm60xx/atbm60xx.mk

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (1) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Driver fix ships with no on-camera test evidence 📘 Rule violation ☼ Reliability

Description

The PR description's "Hardware tested on" section states the change was "Not run on a camera with an
AltoBeam adapter" and that the only evidence is a qemu-bench emulation. The diff repins
ATBM_WIFI_SITE/ATBM_WIFI_VERSION and the ATBM60XX_VERSION and ATBM603X_COMB_OPENIPC_VERSION
pins to driver code that changes the Wi-Fi RX path on every camera using these adapters, so it
alters what the firmware does on a camera. The only camera-side numbers in the description come from
a reporter's configuration in a table, not from a run by this PR's author, and the qemu run never
exercises Ethernet or the reply-reading path the bug depends on. Shipping this to cameras on that
evidence means any regression in RX memory or socket behaviour reaches the field before anyone has
observed it on hardware.

Code

general/package/atbm-wifi/atbm-wifi.mk[R9-10]

+ATBM_WIFI_SITE = $(call github,openipc,atbm-wifi,$(ATBM_WIFI_VERSION))
+ATBM_WIFI_VERSION = 5a0a920b9d8e5161606764dac27761e9e985495d

Evidence

Rule 3 fails when the description states the change was not tested on hardware and the diff can
change what the firmware does on a camera. The PR description's hardware section says it was not run
on a camera with an AltoBeam adapter, and the atbm-wifi pin change selects the RX driver code that
runs on that camera.

Rule 3: Hardware evidence is present and honest
general/package/atbm-wifi/atbm-wifi.mk[9-10]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR repins the AltoBeam Wi-Fi driver packages (atbm-wifi, atbm60xx, atbm603x-comb-openipc) to commits that change the camera's RX path. The PR description states this was not run on a real camera with an AltoBeam adapter; the only test is a qemu-bench emulation that never reads the replies that trigger the bug.
## Fix Focus Areas
- general/package/atbm-wifi/atbm-wifi.mk[7-10]
- general/package/atbm60xx/atbm60xx.mk[12-12]
- general/package/atbm603x-comb-openipc/atbm603x-comb-openipc.mk[10-10]
## Recommended Fix
Run the affected image on a real GK7205V210 or GK7201V200 camera with an ATBM6012B or ATBM603x USB adapter under the reporter's workload (RTMP upload over Wi-Fi with reads of server replies). Record before/after output from the camera: `/proc/meminfo` and `Slab` over a multi-minute run, `TCP: mem` from `/proc/net/sockstat` or equivalent, and whether OOM occurs. Put the output in the PR description, check the hardware-verification boxes only once that output exists, and drop the qemu-only framing if no hardware run is achieved.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can hide the parts of a finding you never read, like the evidence or the agent prompt

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[widgetii]

On qodo's "no on-camera test evidence": correct, and the description says so. This lands on the qemu-bench evidence, and hardware confirmation goes to the reporter in #2455.

One correction: the emulation does exercise the path the bug depends on. The failing case is an upload whose application never reads the server's replies, and that is exactly what both A/B arms ran: stock OOM within 30 s, this change flat. Ethernet isn't part of the bug, since its driver does not carve received frames out of 32 KiB page-frag blocks.