A memory leak was detected when activating the Outgoing RTMP stream. gk7205v210_lite_vixand-ivg-g4f-a-w

GK7205V210 + IMX307 (RAM 64Mb, Flash 16Mb)
The firmware works well, but there's just one problem: when I enable the RTMP Outgoing stream, the Majestic starts gradually increasing its memory consumption from 62% to 90%. This memory grows proportionally to the transmitted stream; the more intense the stream, the faster it grows. If I cover the lens, the memory growth stops, but there's no decrease. When memory consumption reaches 90%, the camera starts to lag, the outgoing stream stops, and sometimes the watchdog resets it.
CPU load and temperature are within normal ranges.

Thanks — the screenshot carried a lot: H.265 1920x1080 @ 25 fps, 4096 kbit/s, sub stream off, snapshots on, Wi-Fi, 26 MB of RAM visible to Linux, ~49 min uptime, and the outgoing stream still flowing at the moment you took it (the network graph tracks the encoder graph).

What we tried on the bench

We put a lab camera into the same shape as yours: same SoC family, same IMX307 sensor, H.265 1920x1080 @ 25 fps, 4096 kbit/s, sub stream off, JPEG snapshots on, publishing continuously to an RTMP server. To make the "the more intense the stream, the faster it grows" case as harsh as we could, we pinned the encoder to CBR so it pushes a constant ~4.3 Mbit/s no matter what the lens sees — several times your average.

Resident memory of the streamer process, across everything we could think of to vary:

what	how long	published	memory
plain `rtmp://`	10 min	190 MB	5524 → 5524 kB
`rtmps://`, plus a browser-shaped load (snapshot every 5 s + metrics polling)	10.4 min	338 MB	5528 → 5552 kB
connection churn — server taken away, camera retrying every 10 s	5 min	—	went down
deliberately bad link — 120 ms of jitter, 3% packet loss, throttled to 2 Mbit/s while the encoder pushed 4.3	5.5 min	128 MB	flat
audio enabled, so a second encoder joins the path	15.5 min	508 MB	5780 → 5792 kB

System free and available memory were flat throughout too.

So on our bench the publishing path does not grow, and the difference we cannot rule out from here is your link: you publish over Wi-Fi, we published over Ethernet.

The measurement that would settle it

The memory card in the web UI is a system-wide figure. It cannot tell you whether the memory belongs to the streamer or to the kernel — a Wi-Fi driver's buffers under sustained transmit, for instance, look exactly the same on that card. Could you run this on the camera and leave it going for the whole 62% → 90% climb?

( while :; do
    P=$(pidof majestic)
    printf '%s rss=%s ' "$(date -Iseconds)" "$(awk '/VmRSS/{print $2}' /proc/$P/status)"
    awk '/^(MemFree|MemAvailable|Shmem|Slab|SReclaimable|SUnreclaim):/{printf "%s=%s ", $1, $2}' /proc/meminfo
    printf 'tmp=%s\n' "$(df /tmp | awk 'NR==2{print $3}')"
    sleep 30
  done ) > /tmp/mem311.log 2>&1 &

Then attach /tmp/mem311.log. It splits the problem three ways in one shot:

rss climbing → it is the streamer, and we will have a reproducible target;
rss flat while SUnreclaim climbs → it is the kernel, and on a Wi-Fi camera under continuous transmit the driver is the first suspect;
Shmem / tmp climbing → something is filling the RAM filesystem.

Also useful, whenever convenient:

the outgoing: section of /etc/majestic.yaml (please blank the stream key) — in particular whether the address is rtmp:// or rtmps://, and whether the destination is on your LAN or a service on the internet;
whether the climb also happens with the camera on Ethernet instead of Wi-Fi, if that is possible on this board;
logread covering the climb.

One half of it we did reproduce

Not the memory, but this: when the receiving end stops accepting data, the camera does not merely lose the outgoing stream — it stops answering everything, web UI and RTSP included, for as long as the receiver is not draining. On the bench, HTTP replies went from 0.1 s to no reply at all within a minute of the receiver being frozen, and came back instantly the moment it resumed. Even a merely congested link shows a milder version: on the throttled link above, web UI response time went from 0.10 s to 0.34–1.02 s.

A fix for that is written and in review. With it, the same frozen receiver costs one hiccup of a few seconds and then the camera carries on serving normally and reconnects on its own.

On a Wi-Fi link that stalls now and then, that is a good explanation for the "camera starts to lag, the outgoing stream stops, and sometimes the watchdog resets it" part of your report — though not for the memory climb, which is why the log above still matters.

Thank you. Sending you new data. I'll try connecting the camera via LAN a little later.

/tmp# cat mem311.log
2026-09-02T18:19:50+03:00 rss=5672 MemFree:=1076 MemAvailable:=9264 Shmem:=96 Slab:=5392 SReclaimable:=1588 SUnreclaim:=3804 tmp=12
2026-09-02T18:20:20+03:00 rss=5788 MemFree:=1288 MemAvailable:=8280 Shmem:=104 Slab:=5336 SReclaimable:=1548 SUnreclaim:=3788 tmp=20
2026-09-02T18:20:51+03:00 rss=5796 MemFree:=1192 MemAvailable:=7604 Shmem:=104 Slab:=5476 SReclaimable:=1528 SUnreclaim:=3948 tmp=20
2026-09-02T18:21:21+03:00 rss=5796 MemFree:=1340 MemAvailable:=7416 Shmem:=104 Slab:=5352 SReclaimable:=1504 SUnreclaim:=3848 tmp=20
2026-09-02T18:21:51+03:00 rss=5796 MemFree:=1184 MemAvailable:=6940 Shmem:=104 Slab:=5440 SReclaimable:=1504 SUnreclaim:=3936 tmp=20
2026-09-02T18:22:21+03:00 rss=5796 MemFree:=1500 MemAvailable:=6852 Shmem:=104 Slab:=5268 SReclaimable:=1500 SUnreclaim:=3768 tmp=20
2026-09-02T18:22:51+03:00 rss=5568 MemFree:=1072 MemAvailable:=6692 Shmem:=104 Slab:=5280 SReclaimable:=1504 SUnreclaim:=3776 tmp=20
2026-09-02T18:23:21+03:00 rss=4592 MemFree:=1140 MemAvailable:=5448 Shmem:=104 Slab:=5284 SReclaimable:=1504 SUnreclaim:=3780 tmp=20
2026-09-02T18:23:51+03:00 rss=3920 MemFree:=1752 MemAvailable:=4224 Shmem:=104 Slab:=5348 SReclaimable:=1428 SUnreclaim:=3920 tmp=20
2026-09-02T18:24:21+03:00 rss=3816 MemFree:=1760 MemAvailable:=3912 Shmem:=104 Slab:=5244 SReclaimable:=1424 SUnreclaim:=3820 tmp=20
2026-09-02T18:24:53+03:00 rss=3348 MemFree:=1008 MemAvailable:=2896 Shmem:=104 Slab:=4948 SReclaimable:=1156 SUnreclaim:=3792 tmp=20
2026-09-02T18:25:24+03:00 rss=3636 MemFree:=912 MemAvailable:=2484 Shmem:=104 Slab:=4512 SReclaimable:=540 SUnreclaim:=3972 tmp=20
2026-09-02T18:25:56+03:00 rss=3000 MemFree:=1076 MemAvailable:=1992 Shmem:=104 Slab:=4400 SReclaimable:=456 SUnreclaim:=3944 tmp=20
2026-09-02T18:26:26+03:00 rss=2760 MemFree:=1028 MemAvailable:=1872 Shmem:=104 Slab:=4388 SReclaimable:=452 SUnreclaim:=3936 tmp=20
2026-09-02T18:26:58+03:00 rss=3032 MemFree:=1012 MemAvailable:=2056 Shmem:=104 Slab:=4468 SReclaimable:=456 SUnreclaim:=4012 tmp=20
2026-09-02T18:27:30+03:00 rss=2992 MemFree:=920 MemAvailable:=1624 Shmem:=104 Slab:=4392 SReclaimable:=468 SUnreclaim:=3924 tmp=20
2026-09-02T18:28:00+03:00 rss=2696 MemFree:=904 MemAvailable:=1768 Shmem:=104 Slab:=4384 SReclaimable:=448 SUnreclaim:=3936 tmp=20
2026-09-02T18:28:32+03:00 rss=2396 MemFree:=968 MemAvailable:=1444 Shmem:=104 Slab:=4472 SReclaimable:=528 SUnreclaim:=3944 tmp=20

cat /etc/majestic.yaml

Managed by majestic. Comments and formatting are removed when settings change

via the web UI or API.

system:
webPort: 80
httpsPort: 443
logLevel: debug
unsafe: false
buffer: 1024
plugins: false
staticDir: /var/www
telemetry: false
isp:
antiFlicker: disabled
sensorConfig: /etc/sensors/imx307_i2c_2l_1080p_30fps.ini
slowShutter: medium
rawMode: slow
dis: false
memMode: reduction
lowDelay: false
yuvCompression: auto
iris:
type: none
manual: false
holdValue: 610
kp: 7000
ki: 100
kd: 3000
minPwmDuty: 250
maxPwmDuty: 950
openPwmDuty: 800
autofocus:
enabled: false
actuator: pelco-xm
port: /dev/ttyAMA0
speed: 115200
blkCnt: 4
image:
mirror: false
flip: false
contrast: 50
hue: 50
saturation: 50
luminance: 50
rotate: 0
tuning: false
video0:
codec: h265
fps: 25
bitrate: 4096
adjustBitrate: false
osd: true
rcMode: vbr
profile: main
crop: []
enabled: true
gopSize: "1"
size: 1920x1080
gopMode: normal
svct: "off"
sliceUnits: 0
sliceBytes: 0
minQp: 28
maxQp: 42
minIp: 1
maxIp: 2
video1:
codec: h264
fps: 15
bitrate: 1024
adjustBitrate: true
osd: true
rcMode: vbr
profile: main
crop: []
size: 640x360
enabled: false
gopMode: normal
svct: "off"
sliceUnits: 0
sliceBytes: 0
minQp: 28
maxQp: 42
minIp: 1
maxIp: 2
usbcam:
enabled: false
device: /dev/video0
codec: auto
cameraId: 1
size: 1280x720
fps: 30
sliceUnits: 0
gopSize: "1.0"
transcode:
codec: h264
uvcgadget:
enabled: false
device: /dev/video0
format: mjpeg
size: 1280x720
fps: 30
jpeg:
enabled: true
qfactor: 50
fps: 5
osd: true
rtsp: false
tuned: ""
osd:
enabled: false
template: "%d.%m.%Y %H:%M:%S"
font: /usr/share/fonts/truetype/UbuntuMono-Regular.ttf
size: "0.6"
weight: thin
outline: true
anchor: top-left
offsetX: "0"
offsetY: "0"
posX: 16
posY: 16
bgAlpha: 0
privacyMasks: []
audio:
enabled: true
volume: 48
srate: "8000"
codec: aac
outputEnabled: false
outputVolume: 30
speakerPinInvert: false
jitterBufferMs: 0
dual: false
rtsp:
enabled: true
port: 554
backchannel: false
audioCodec: ""
webrtc:
iceServers: "stun:stun.cloudflare.com:3478"
sip:
enabled: false
server: ""
port: 5060
username: ""
password: ""
localUri: ""
callTarget: ""
localIp: ""
localPort: 5060
doRegister: true
registerExpires: 3600
buttonActiveLow: true
rtpPortHint: 5004
ringMode: sequential
ringSeconds: 10
ringCycles: 3
nightMode:
colorToGray: false
irCutSingleInvert: false
lightMonitor: false
lightSensorInvert: false
monitorDelay: 0
irCutPin1: 9
irCutPin2: 8
backlightPin: 4
minThreshold: 2000
maxThreshold: 14000
motionDetect:
enabled: false
visualize: false
debug: false
roi: []
sensitivity: 3
records:
enabled: false
path: "/mnt/mmcblk0p1/%F"
filename: "%H-%M"
split: 20
maxUsage: 95
substream: false
audioCodec: ""
dualcam: false
outgoing:
enabled: true
naluSize: 1200
substream: true
audioSource: auto
audioCodec: ""
server: "rtmp://a.rtmp.youtube.com/live2/..."
watchdog:
enabled: true
timeout: 300
hls:
enabled: false
mdns:
enabled: true
onvif:
enabled: true
username: root
password: ""
ipeye:
enabled: false
netip:
enabled: false
snapshots: false
ignoreSetTime: false
cloud:
enabled: false
host: ""
port: 8443

Thank you — that log answers the main question, and the answer is that it is not the streamer's own memory.

Your log, first sample to last, over 8 minutes 42 seconds:

	first	last	change
majestic RSS	5672 kB	2396 kB	−3276
MemAvailable	9264 kB	1444 kB	−7820
Slab	5392 kB	4472 kB	−920
SUnreclaim	3804 kB	3944 kB	+140
Shmem	96 kB	104 kB	+8
/tmp used	12 kB	20 kB	+8

Majestic's own memory holds flat at about 5.7–5.8 MB for the first two and a half minutes, and then falls to 2.4 MB. That drop is not the streamer releasing anything — a program's heap does not halve. This board has no swap, so when memory runs short the kernel reclaims the one thing it can always get back later: the executable code of running programs, which it can re-read from flash. Majestic's code pages get evicted, and from then on every function it calls has to be faulted back in off flash before it can run.

That is what "the camera starts to lag" actually is. The streamer is the victim of the shortage here, not its cause.

Everything the streamer could be responsible for stays flat throughout: unreclaimable kernel memory barely moves (+140 kB), shared memory is flat, /tmp is flat at 20 kB.

So: counting the 7.8 MB that vanished, plus the 3.3 MB majestic was forced to give back, plus the 1 MB of reclaimable slab the kernel dropped, something consumed on the order of 12 MB in 8.7 minutes — and it is invisible in every field we sampled. That points to memory the kernel allocates in whole pages rather than through the slab allocator. Network buffers and device-driver rings are exactly that, which fits this happening on Wi-Fi and not on our Ethernet bench.

One thing to fix in your config regardless

Your outgoing: section has substream: true, but video1 has enabled: false. With the substream switched off there is nothing for the camera to publish, so it falls back to publishing video0 — silently, with nothing in the log to tell you.

What is actually going out is therefore not the 640x360 H.264 at 1024 kbit/s your config describes. It is video0: 1920x1080 H.265 at 4096 kbit/s, with gopSize: 1 — a keyframe every single second, which pushes the real rate higher still. That is roughly four times the data you meant to send, over the Wi-Fi link that is our main suspect, and you have told us the growth tracks how much data is being sent.

Setting video1.enabled: true gives you the stream you configured. It is also worth doing as an experiment: if the climb slows by roughly the ratio between the two bitrates, that confirms the mechanism scales with traffic and narrows where we look.

A camera that quietly publishes something other than what its config asks for is our problem, not yours, and we will make it say so.

The measurement that would name the consumer

Please run this in the current configuration first, before changing the substream setting, so we are measuring the state that reproduces:

( while :; do
    date -Iseconds
    awk '/^(MemTotal|MemFree|MemAvailable|Buffers|Cached|AnonPages|Mapped|Shmem|Slab|SReclaimable|SUnreclaim|PageTables|VmallocUsed):/' /proc/meminfo
    cat /proc/net/sockstat
    for s in /proc/[0-9]*/status; do
      awk '/^Name:/{n=$2} /^VmRSS:/{print $2, n}' "$s"
    done 2>/dev/null | sort -rn | head -8
    echo ---
    sleep 30
  done ) > /tmp/mem311b.log 2>&1 &

Three things it adds over the last one:

/proc/net/sockstat — the mem figure on the TCP: line is how many pages the kernel is holding in socket buffers, and orphan counts connections closed while they still had unsent data. If either climbs, the memory is in the network stack, and that is something we can act on directly.
the full meminfo — Cached and AnonPages distinguish anonymous memory from file-backed, which the six fields we sampled last time could not.
the top eight processes by memory — rules out anything other than majestic growing.

Two other things would help as much:

the LAN test you offered. That is the most valuable single data point left — we could not produce any growth at all over Ethernet, including with audio on and a deliberately degraded link.
logread covering the climb. You have logLevel: debug set, so it should be detailed. We asked last time and it may simply have been missed.

On the other half of the report

The fix for the stall — the camera going silent on the web UI and RTSP when the receiving end stops accepting data — has landed and will appear in nightly builds. It does not address the memory climb, and we are not treating this issue as solved.

I checked the camera's behavior with a LAN connection - everything is fine, the memory grows from 52% to 70% and then drops again.
Regarding the RTMP substream, I tried disabling and enabling it, but it didn't resolve the issue. I left it enabled during the test, as you requested.
Here is the result of new measurements:

/tmp# cat mem311b.log
2026-09-02T23:18:44+03:00
MemTotal: 27336 kB
MemFree: 1064 kB
MemAvailable: 9760 kB
Buffers: 3748 kB
Cached: 6072 kB
AnonPages: 2488 kB
Mapped: 5156 kB
Shmem: 96 kB
Slab: 5316 kB
SReclaimable: 1548 kB
SUnreclaim: 3768 kB
PageTables: 212 kB
VmallocUsed: 0 kB
sockets: used 37
TCP: inuse 3 orphan 0 tw 0 alloc 6 mem 7
UDP: inuse 2 mem 1
UDPLITE: inuse 0
RAW: inuse 0
FRAG: inuse 0 memory 0
5736 majestic
944 wpa_supplicant
932 fake-hwclock
912 sh
840 syslogd
812 ntpd
768 sort
744 sh

2026-09-02T23:19:15+03:00
MemTotal: 27336 kB
MemFree: 1356 kB
MemAvailable: 8680 kB
Buffers: 2196 kB
Cached: 6260 kB
AnonPages: 2692 kB
Mapped: 5148 kB
Shmem: 104 kB
Slab: 5336 kB
SReclaimable: 1548 kB
SUnreclaim: 3788 kB
PageTables: 212 kB
VmallocUsed: 0 kB
sockets: used 38
TCP: inuse 3 orphan 0 tw 14 alloc 7 mem 26
UDP: inuse 2 mem 1
UDPLITE: inuse 0
RAW: inuse 0
FRAG: inuse 0 memory 0
5936 majestic
944 wpa_supplicant
932 fake-hwclock
912 sh
840 syslogd
832 sh
812 ntpd
748 sort

2026-09-02T23:19:45+03:00
MemTotal: 27336 kB
MemFree: 1244 kB
MemAvailable: 7560 kB
Buffers: 1248 kB
Cached: 6216 kB
AnonPages: 2692 kB
Mapped: 5148 kB
Shmem: 104 kB
Slab: 5280 kB
SReclaimable: 1516 kB
SUnreclaim: 3764 kB
PageTables: 216 kB
VmallocUsed: 0 kB
sockets: used 38
TCP: inuse 3 orphan 0 tw 26 alloc 7 mem 12
UDP: inuse 2 mem 2
UDPLITE: inuse 0
RAW: inuse 0
FRAG: inuse 0 memory 0
5936 majestic
944 wpa_supplicant
932 fake-hwclock
912 sh
840 syslogd
832 sh
812 ntpd
748 head

2026-09-02T23:20:16+03:00
MemTotal: 27336 kB
MemFree: 1348 kB
MemAvailable: 6604 kB
Buffers: 880 kB
Cached: 5536 kB
AnonPages: 2700 kB
Mapped: 4596 kB
Shmem: 104 kB
Slab: 5372 kB
SReclaimable: 1496 kB
SUnreclaim: 3876 kB
PageTables: 216 kB
VmallocUsed: 0 kB
sockets: used 38
TCP: inuse 3 orphan 0 tw 22 alloc 7 mem 15
UDP: inuse 2 mem 2
UDPLITE: inuse 0
RAW: inuse 0
FRAG: inuse 0 memory 0
5764 majestic
932 fake-hwclock
912 sh
840 syslogd
832 sh
812 ntpd
764 sort
744 sh

2026-09-02T23:20:46+03:00
MemTotal: 27336 kB
MemFree: 1332 kB
MemAvailable: 5720 kB
Buffers: 956 kB
Cached: 4592 kB
AnonPages: 2700 kB
Mapped: 3908 kB
Shmem: 104 kB
Slab: 5284 kB
SReclaimable: 1496 kB
SUnreclaim: 3788 kB
PageTables: 220 kB
VmallocUsed: 0 kB
sockets: used 38
TCP: inuse 3 orphan 0 tw 25 alloc 7 mem 18
UDP: inuse 2 mem 2
UDPLITE: inuse 0
RAW: inuse 0
FRAG: inuse 0 memory 0
5340 majestic
932 fake-hwclock
912 sh
840 syslogd
832 sh
812 ntpd
768 sort
744 sh

2026-09-02T23:21:17+03:00
MemTotal: 27336 kB
MemFree: 1456 kB
MemAvailable: 5268 kB
Buffers: 952 kB
Cached: 4020 kB
AnonPages: 2696 kB
Mapped: 3392 kB
Shmem: 104 kB
Slab: 5264 kB
SReclaimable: 1496 kB
SUnreclaim: 3768 kB
PageTables: 216 kB
VmallocUsed: 0 kB
sockets: used 38
TCP: inuse 3 orphan 0 tw 29 alloc 7 mem 19
UDP: inuse 2 mem 2
UDPLITE: inuse 0
RAW: inuse 0
FRAG: inuse 0 memory 0
4828 majestic
932 fake-hwclock
912 sh
840 syslogd
832 sh
812 ntpd
744 sh
744 crond

2026-09-02T23:21:48+03:00
MemTotal: 27336 kB
MemFree: 1144 kB
MemAvailable: 4844 kB
Buffers: 1020 kB
Cached: 3844 kB
AnonPages: 2688 kB
Mapped: 3096 kB
Shmem: 104 kB
Slab: 5372 kB
SReclaimable: 1484 kB
SUnreclaim: 3888 kB
PageTables: 216 kB
VmallocUsed: 0 kB
sockets: used 38
TCP: inuse 3 orphan 0 tw 31 alloc 7 mem 35
UDP: inuse 2 mem 2
UDPLITE: inuse 0
RAW: inuse 0
FRAG: inuse 0 memory 0
4464 majestic
932 fake-hwclock
912 sh
840 syslogd
832 sh
812 ntpd
784 head
744 sh

2026-09-02T23:22:18+03:00
MemTotal: 27336 kB
MemFree: 1368 kB
MemAvailable: 3080 kB
Buffers: 384 kB
Cached: 2572 kB
AnonPages: 2932 kB
Mapped: 2380 kB
Shmem: 108 kB
Slab: 5236 kB
SReclaimable: 1412 kB
SUnreclaim: 3824 kB
PageTables: 216 kB
VmallocUsed: 0 kB
sockets: used 39
TCP: inuse 3 orphan 0 tw 31 alloc 8 mem 51
UDP: inuse 2 mem 2
UDPLITE: inuse 0
RAW: inuse 0
FRAG: inuse 0 memory 0
4004 majestic
796 sort
792 head
748 sh
748 fake-hwclock
728 sh
704 sh
688 syslogd

2026-09-02T23:22:51+03:00
MemTotal: 27336 kB
MemFree: 1032 kB
MemAvailable: 2192 kB
Buffers: 712 kB
Cached: 2124 kB
AnonPages: 3620 kB
Mapped: 1636 kB
Shmem: 108 kB
Slab: 4476 kB
SReclaimable: 468 kB
SUnreclaim: 4008 kB
PageTables: 216 kB
VmallocUsed: 0 kB
sockets: used 43
TCP: inuse 3 orphan 0 tw 27 alloc 12 mem 30
UDP: inuse 2 mem 2
UDPLITE: inuse 0
RAW: inuse 0
FRAG: inuse 0 memory 0
4328 majestic
772 sort
744 sh
736 head
584 status.cgi
228 wpa_supplicant
136 syslogd
108 sh

logread
Jan 1 02:00:02 gk7205v210-imx307 syslog.info syslogd started: BusyBox v1.36.1
Sep 2 23:18:02 gk7205v210-imx307 user.notice fake-hwclock: clock restored to 2026-09-02 20:18:02 UTC
Sep 2 23:18:02 gk7205v210-imx307 kern.notice kernel: klogd started: BusyBox v1.36.1 (2026-09-01 23:40:46 EEST)
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: Booting Linux on physical CPU 0x0
Sep 2 23:18:02 gk7205v210-imx307 kern.notice kernel: Linux version 4.9.37 (xxx@xxx) (buildroot-gcc-13.3.0) #1 Tue Sep 1 23:42:24 EEST 2026
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c53c7d
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: CPU: div instructions available: patching division code
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: OF: fdt:Machine model: Goke GK7205V200 DEMO Board
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: cma zone is not set!
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: Memory policy: Data cache writeback
Sep 2 23:18:02 gk7205v210-imx307 kern.debug kernel: On node 0 totalpages: 8192
Sep 2 23:18:02 gk7205v210-imx307 kern.debug kernel: free_area_init_node: node 0, pgdat c04f2018, node_mem_map c1fbb000
Sep 2 23:18:02 gk7205v210-imx307 kern.debug kernel: Normal zone: 64 pages used for memmap
Sep 2 23:18:02 gk7205v210-imx307 kern.debug kernel: Normal zone: 0 pages reserved
Sep 2 23:18:02 gk7205v210-imx307 kern.debug kernel: Normal zone: 8192 pages, LIFO batch:0
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: CPU: All CPU(s) started in SVC mode.
Sep 2 23:18:02 gk7205v210-imx307 kern.debug kernel: pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
Sep 2 23:18:02 gk7205v210-imx307 kern.debug kernel: pcpu-alloc: [0] 0
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: Built 1 zonelists in Zone order, mobility grouping on. Total pages: 8128
Sep 2 23:18:02 gk7205v210-imx307 kern.notice kernel: Kernel command line: mem=32M console=ttyAMA0,115200 panic=20 rootfstype=squashfs root=/dev/mtdblock3 init=/init mtdparts=sfc:256k(boot),64k(env),2048k(kernel),10240k(rootfs),-(rootfs_data) mmz_allocator=gk
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: PID hash table entries: 128 (order: -3, 512 bytes)
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: Memory: 27140K/32768K available (3787K kernel code, 138K rwdata, 904K rodata, 196K init, 178K bss, 5628K reserved, 0K cma-reserved)
Sep 2 23:18:02 gk7205v210-imx307 kern.notice kernel: Virtual kernel memory layout:
Sep 2 23:18:02 gk7205v210-imx307 kern.notice kernel: vector : 0xffff0000 - 0xffff1000 ( 4 kB)
Sep 2 23:18:02 gk7205v210-imx307 kern.notice kernel: fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
Sep 2 23:18:02 gk7205v210-imx307 kern.notice kernel: vmalloc : 0xc2800000 - 0xff800000 ( 976 MB)
Sep 2 23:18:02 gk7205v210-imx307 kern.notice kernel: lowmem : 0xc0000000 - 0xc2000000 ( 32 MB)
Sep 2 23:18:02 gk7205v210-imx307 kern.notice kernel: modules : 0xbf000000 - 0xc0000000 ( 16 MB)
Sep 2 23:18:02 gk7205v210-imx307 kern.notice kernel: .text : 0xc0008000 - 0xc03bb088 (3789 kB)
Sep 2 23:18:02 gk7205v210-imx307 kern.notice kernel: .init : 0xc049f000 - 0xc04d0000 ( 196 kB)
Sep 2 23:18:02 gk7205v210-imx307 kern.notice kernel: .data : 0xc04d0000 - 0xc04f2820 ( 139 kB)
Sep 2 23:18:02 gk7205v210-imx307 kern.notice kernel: .bss : 0xc04f4000 - 0xc05208e8 ( 179 kB)
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: NR_IRQS:16 nr_irqs:16 16
Sep 2 23:18:02 gk7205v210-imx307 kern.err kernel: Gic dist init...
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: arm_arch_timer: Architected cp15 timer(s) running at 50.00MHz (phys).
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0xb8812736b, max_idle_ns: 440795202655 ns
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: sched_clock: 56 bits at 50MHz, resolution 20ns, wraps every 4398046511100ns
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: Switching to timer-based delay loop, resolution 20ns
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: clocksource: arm,sp804: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 637086815595 ns
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: Calibrating delay loop (skipped), value calculated using timer frequency.. 100.00 BogoMIPS (lpj=500000)
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: pid_max: default: 32768 minimum: 301
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: CPU: Testing write buffer coherency: ok
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: Setting up static identity map for 0x40008200 - 0x40008258
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: devtmpfs: initialized
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: VFP support v0.3: implementor 41 architecture 2 part 30 variant 7 rev 5
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: futex hash table entries: 256 (order: -1, 3072 bytes)
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: pinctrl core: initialized pinctrl subsystem
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: NET: Registered protocol family 16
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: DMA: preallocated 256 KiB pool for atomic coherent allocations
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: Serial: AMBA PL011 UART driver
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: 12040000.uart: ttyAMA0 at MMIO 0x12040000 (irq = 21, base_baud = 0) is a PL011 rev2
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: console [ttyAMA0] enabled
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: 12041000.uart: ttyAMA1 at MMIO 0x12041000 (irq = 22, base_baud = 0) is a PL011 rev2
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: 12042000.uart: ttyAMA2 at MMIO 0x12042000 (irq = 23, base_baud = 0) is a PL011 rev2
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: ssp-pl022 12070000.spi: ARM PL022 driver, device ID: 0x00041022
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: ssp-pl022 12070000.spi: mapped registers from 0x12070000 to c286f000
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: usbcore: registered new interface driver usbfs
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: usbcore: registered new interface driver hub
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: usbcore: registered new device driver usb
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: clocksource: Switched to clocksource arch_sys_counter
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: NET: Registered protocol family 2
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: TCP established hash table entries: 1024 (order: 0, 4096 bytes)
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: TCP: Hash tables configured (established 1024 bind 1024)
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: UDP hash table entries: 256 (order: 0, 4096 bytes)
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: NET: Registered protocol family 1
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: RPC: Registered named UNIX socket transport module.
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: RPC: Registered udp transport module.
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: RPC: Registered tcp transport module.
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: RPC: Registered tcp NFSv4.1 backchannel transport module.
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: workingset: timestamp_bits=30 max_order=13 bucket_order=0
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: squashfs: version 4.0 (2009/01/31) Phillip Lougher
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: jffs2: version 2.2 (NAND) (ZLIB) (RTIME) (c) 2001-2006 Red Hat, Inc.
Sep 2 23:18:02 gk7205v210-imx307 kern.debug kernel: yaffs: yaffs Installing.
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: io scheduler noop registered
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: io scheduler deadline registered (default)
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: pl061_gpio 120b0000.gpio_chip: PL061 GPIO chip @0x120b0000 registered
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: pl061_gpio 120b1000.gpio_chip: PL061 GPIO chip @0x120b1000 registered
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: pl061_gpio 120b2000.gpio_chip: PL061 GPIO chip @0x120b2000 registered
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: pl061_gpio 120b4000.gpio_chip: PL061 GPIO chip @0x120b4000 registered
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: pl061_gpio 120b5000.gpio_chip: PL061 GPIO chip @0x120b5000 registered
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: pl061_gpio 120b6000.gpio_chip: PL061 GPIO chip @0x120b6000 registered
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: pl061_gpio 120b7000.gpio_chip: PL061 GPIO chip @0x120b7000 registered
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: pl061_gpio 120b8000.gpio_chip: PL061 GPIO chip @0x120b8000 registered
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: brd: module loaded
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: loop: module loaded
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: bsp-sfc bsp_spi_nor.0: SPI Nor ID Table Version 1.3
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: bsp-sfc bsp_spi_nor.0: Force global unlock
Sep 2 23:18:02 gk7205v210-imx307 kern.warn kernel: bsp-sfc bsp_spi_nor.0: all blocks are unlocked.
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: bsp-sfc bsp_spi_nor.0: SR1 [00], SR2 [00], SR3 [00]
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: bsp-sfc bsp_spi_nor.0: FM25Q128-SOB-T-G (Chipsize 16 Mbytes, Blocksize 64KiB)
Sep 2 23:18:02 gk7205v210-imx307 kern.notice kernel: 5 cmdlinepart partitions found on MTD device sfc
Sep 2 23:18:02 gk7205v210-imx307 kern.notice kernel: 5 cmdlinepart partitions found on MTD device sfc
Sep 2 23:18:02 gk7205v210-imx307 kern.notice kernel: Creating 5 MTD partitions on "sfc":
Sep 2 23:18:02 gk7205v210-imx307 kern.notice kernel: 0x000000000000-0x000000040000 : "boot"
Sep 2 23:18:02 gk7205v210-imx307 kern.notice kernel: 0x000000040000-0x000000050000 : "env"
Sep 2 23:18:02 gk7205v210-imx307 kern.notice kernel: 0x000000050000-0x000000250000 : "kernel"
Sep 2 23:18:02 gk7205v210-imx307 kern.notice kernel: 0x000000250000-0x000000c50000 : "rootfs"
Sep 2 23:18:02 gk7205v210-imx307 kern.notice kernel: 0x000000c50000-0x000001000000 : "rootfs_data"
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: SPI Nand ID Table Version 2.7
Sep 2 23:18:02 gk7205v210-imx307 kern.err kernel: Cannot found a valid SPI Nand Device
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: bsp_spi_nand_probe(157): Error: driver probe, result: -19
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: FEPHY:addr=1, la_am=0x9, ldo_am=0x4, r_tuning=0x21
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: libphy: femac_mii_bus: probed
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: libphy: Fixed MDIO Bus: probed
Sep 2 23:18:02 gk7205v210-imx307 kern.warn kernel: femac 10040000.ethernet: using random MAC address d6:e3:7f:85:ba:3f
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: Generic PHY 10041100.mdio:01: attached PHY driver [Generic PHY] (mii_bus:phy_addr=10041100.mdio:01, irq=-1)
Sep 2 23:18:02 gk7205v210-imx307 kern.err kernel: phy_id=0x20669906, phy_mode=mii
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 1
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: xhci-hcd xhci-hcd.0.auto: hcc params 0x0220fe6c hci version 0x110 quirks 0x20010010
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: xhci-hcd xhci-hcd.0.auto: irq 116, io mem 0x10030000
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: hub 1-0:1.0: USB hub found
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: hub 1-0:1.0: 1 port detected
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 2
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: hub 2-0:1.0: USB hub found
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: hub 2-0:1.0: hub can't support USB3.0
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: goke_rtc 120e0000.rtc: rtc core: registered 120e0000.rtc as rtc0
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: goke_rtc 120e0000.rtc: RTC driver for goke enabled
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: i2c /dev entries driver
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: goke-i2c 12060000.i2c: goke-i2c0@100000hz registered
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: goke-i2c 12061000.i2c: goke-i2c1@100000hz registered
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: goke-i2c 12062000.i2c: goke-i2c2@100000hz registered
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: sdhci: Secure Digital Host Controller Interface driver
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: sdhci: Copyright(c) Pierre Ossman
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: sdhci-pltfm: SDHCI platform and OF driver helper
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: mmc0: SDHCI controller on 10010000.sdhci [10010000.sdhci] using ADMA in legacy mode
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: usb 1-1: new high-speed USB device number 2 using xhci-hcd
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: mmc1: SDHCI controller on 10020000.sdhci [10020000.sdhci] using ADMA in legacy mode
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: ip_tables: (C) 2000-2006 Netfilter Core Team
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: NET: Registered protocol family 10
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: NET: Registered protocol family 17
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this.
Sep 2 23:18:02 gk7205v210-imx307 kern.err kernel: goke_rtc 120e0000.rtc: hctosys: unable to read the hardware clock
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: VFS: Mounted root (squashfs filesystem) readonly on device 31:3.
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: devtmpfs: mounted
Sep 2 23:18:02 gk7205v210-imx307 kern.info kernel: Freeing unused kernel memory: 196K (c049f000 - c04d0000)
Sep 2 23:18:02 gk7205v210-imx307 kern.warn kernel: This architecture does not have kernel memory protection.
Sep 2 23:18:02 gk7205v210-imx307 kern.notice kernel: random: crng init done
Sep 2 23:18:02 gk7205v210-imx307 kern.info sysctl: * Applying /etc/sysctl.conf ...
Sep 2 23:18:02 gk7205v210-imx307 kern.info sysctl: kernel.printk = 3 3 1 3
Sep 2 23:18:02 gk7205v210-imx307 kern.err sysctl: sysctl: error: 'net.core.bpf_jit_enable' is an unknown key
Sep 2 23:18:03 gk7205v210-imx307 kern.warn kernel: atbm6012b_wifi_usb: loading out-of-tree module taints kernel.
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:atbm_usb_module_init 0
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:platform_init(251)
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:SVN_VER=3174,DPLL_CLOCK=2,BUILD_TIME=2026-09-01_23-42-29
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:atbm_usb_probe : idVendor[7a] idProduct[888b]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:AsmLite probe!
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:Probe called -1 v1
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:not CONFIG_USE_DMA_ADDR_BUFFER
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:CONFIG_TX_NO_CONFIRM
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:ble_spin_lock init
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:Allocated hw_priv @ c12190c0
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]: wait_event_interruptible from send_prbresp_wq
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:atbmwifi USB_USE_TASTLET_TXRX enable (c12190c0)
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:atbmwifi USB_USE_TASTLET_TXRX enable (c12190c0)
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:Get 6012B-X UID Success!!support BLE
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:atbm_get_chiptype, chipver=0x4a, g_wifi_chip_type[12]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:atbm_before_load_firmware++
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:+++++++++++++++++1.1v++++++++++++++++++
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:===================_====================
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:atbm_start_load_firmware++
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: ======>>> load only WIFI firmware <<<======
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:START DOWNLOAD ICCM=========
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:atbm_load_firmware_generic: addr 10000: len 15000
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:START DOWNLOAD DCCM=========
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:atbm_load_firmware_generic: addr 800000: len a000
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:atbm_after_load_firmware++
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:usb:try to flush rx....
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:flush rx[-110][0]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:ARES_A:after_load_firmware
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:0x1610102c=0x40a0e
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:0x1610102c=0x10a0f
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:0x16101000=0x8000e08
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:set_block_size=256
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:mdelay wait wsm_startup_done !!
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:firmwareCap f1a9
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:firmwareCap2 11ac
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:wsm_caps.firmwareCap 11acf1a9 4
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:apollo wifi WSM init done.
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: Input buffers: 30 x 1648 bytes
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: Hardware: 7.0
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: WSM firmware [=MODEM==USB=-NoBle-Oct 23 2023 11:12:36], ver: 18378, build: 4220, api: 1060, cap: 0x11ACF1A9 Config[8030408] expection 9006fdc, ep0 cmd addr 0 NumOfStations[8] NumOfInterfaces[3]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:EFUSE(8) [0]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:EFUSE(I) [0]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:EFUSE(B) [0]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:CAPABILITIES_ATBM_PRIVATE_IE [0]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:CAPABILITIES_NVR_IPC [0]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:CAPABILITIES_NO_CONFIRM [1]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:CAPABILITIES_SDIO_PATCH [0]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:CAPABILITIES_NO_BACKOFF [1]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:CAPABILITIES_CFO [0]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:CAPABILITIES_AGC [1]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:CAPABILITIES_TXCAL [1]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:CAPABILITIES_MONITOR [0]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:CAPABILITIES_CUSTOM [0]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:CAPABILITIES_SMARTCONFIG [0]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:CAPABILITIES_ETF [1]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:CAPABILITIES_LMAC_RATECTL [1]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:CAPABILITIES_LMAC_TPC [1]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:CAPABILITIES_LMAC_TEMPC [1]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:CAPABILITIES_CTS_BUG [0]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:CAPABILITIES_USB_RECOVERY_BUG [0]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:CAPABILITIES_USE_IPC [1]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:CAPABILITIES_OUTER_PA [0]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:CAPABILITIES_POWER_CONSUMPTION [1]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:CAPABILITIES_RSSI_DECIDE_TXPOWER [0]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:CAPABILITIES_RTS_LONG_DURATION [1]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:CAPABILITIES_TX_CFO_PPM_CORRECTION[1]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:CAPABILITIES_SHARE_CRYSTAL [0]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:CAPABILITIES_CFO_DCXO_CORRECTION [1]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:CAPABILITIES_HW_CHECKSUM [0]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:CAPABILITIES_SINGLE_CHANNEL_MULRX [0]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:EX_CAPABILITIES_TWO_CHIP_ONE_SOC [0]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:EX_CAPABILITIES_MANUAL_SET_AC [0]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:EX_CAPABILITIES_LMAC_BW_CONTROL [1]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:EX_CAPABILITIES_SUPPORT_TWO_ANTENNA [0]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:EX_CAPABILITIES_ENABLE_STA_REMAIN_ON_CHANNEL [1]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:EX_CAPABILITIES_ENABLE_PS [1]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:EX_CAPABILITIES_TX_REQUEST_FIFO_LINK [0]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:EX_CAPABILITIES_DRIVER_PHY_REG_INIT [0]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:EX_CAPABILITIES_DRIVER_PROCESS_BA [1]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:EX_CAPABILITIES_DRIVER_PHY_REG_INIT[0]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:EX_CAPABILITIES_DRIVER_PROCESS_BA[1]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:CONFIG_PRODUCT_TEST_USE_FEATURE_ID [1]
Sep 2 23:18:03 gk7205v210-imx307 kern.err kernel: [atbm_log]:CONFIG_PRODUCT_TEST_USE_GOLDEN_LED [1]
Sep 2 23:18:04 gk7205v210-imx307 kern.err kernel: [atbm_log]:not need phy init in driver
Sep 2 23:18:04 gk7205v210-imx307 kern.err kernel: [atbm_log]:wsm_generic_confirm:status(2)
Sep 2 23:18:04 gk7205v210-imx307 kern.err kernel: [atbm_log]: wsm_write_mib fail !!! mibId=4132
Sep 2 23:18:04 gk7205v210-imx307 kern.err kernel: [atbm_log]:efuse data is [0x1,0x2c,0x1f,0x1f,0x1e,0xe,0x0,0x0,0x48:0xa4:0xfd:0x52:0x6b:0xa3]
Sep 2 23:18:04 gk7205v210-imx307 kern.err kernel: [atbm_log]:apollo wifi : can't open /tmp/.mac.info
Sep 2 23:18:04 gk7205v210-imx307 kern.err kernel: [atbm_log]:chip is 6012B not support HT40!
Sep 2 23:18:04 gk7205v210-imx307 kern.err kernel: [atbm_log]:apollo wifi : can't open /tmp/atbm_txpwer_dcxo_cfg.txt
Sep 2 23:18:04 gk7205v210-imx307 kern.err kernel: [atbm_log]:apollo wifi : can't open /tmp/set_rate_power.txt
Sep 2 23:18:04 gk7205v210-imx307 kern.err kernel: [atbm_log]:get chip id [834][10][0]
Sep 2 23:18:04 gk7205v210-imx307 kern.err kernel: [atbm_log]:current chiptype 6012B-X
Sep 2 23:18:04 gk7205v210-imx307 kern.err kernel: [atbm_log]:cfg80211_regdomain is NULL
Sep 2 23:18:04 gk7205v210-imx307 kern.err kernel: [atbm_log]:country code 00 country_support_chan = 14
Sep 2 23:18:04 gk7205v210-imx307 kern.err kernel: [atbm_log]:enable sg
Sep 2 23:18:04 gk7205v210-imx307 kern.err kernel: [atbm_log]:[wlan0] has been disabled
Sep 2 23:18:04 gk7205v210-imx307 kern.err kernel: [atbm_log]:ieee80211_ble_dev_register
Sep 2 23:18:04 gk7205v210-imx307 kern.err kernel: [atbm_log]:ble start
Sep 2 23:18:04 gk7205v210-imx307 kern.err kernel: [atbm_log]:[ALTOBEAM-ble_recv] start
Sep 2 23:18:04 gk7205v210-imx307 kern.err kernel: [atbm_log]:ble subscribe
Sep 2 23:18:04 gk7205v210-imx307 kern.err kernel: [atbm_log]:ble_platform_probe(c11f4e00)
Sep 2 23:18:04 gk7205v210-imx307 kern.err kernel: [atbm_log]:is registered as 'ALTOBEAM'
Sep 2 23:18:04 gk7205v210-imx307 kern.err kernel: [atbm_log]:[atbm_wtd]:set wtd_probe = 1
Sep 2 23:18:04 gk7205v210-imx307 kern.info kernel: usbcore: registered new interface driver atbm_wlan
Sep 2 23:18:04 gk7205v210-imx307 kern.err kernel: [atbm_log]:[ALTOBEAM-ble_xmit] start
Sep 2 23:18:06 gk7205v210-imx307 kern.err kernel: [atbm_log]:atbm_setup_mac:addr(48a4fd526ba3)
Sep 2 23:18:06 gk7205v210-imx307 kern.err kernel: [atbm_log]:^A3 !!! atbm_vif_setup_params: enabling priv
Sep 2 23:18:06 gk7205v210-imx307 kern.err kernel: [atbm_log]:[STA] Interface ID:0 of type:2 added
Sep 2 23:18:06 gk7205v210-imx307 kern.err kernel: [atbm_log]:atbm_set_uapsd_param:uapsdFlags(0)
Sep 2 23:18:06 gk7205v210-imx307 kern.err kernel: [atbm_log]:atbm_set_uapsd_param:uapsdFlags(0)
Sep 2 23:18:06 gk7205v210-imx307 kern.err kernel: [atbm_log]:atbm_set_uapsd_param:uapsdFlags(0)
Sep 2 23:18:06 gk7205v210-imx307 kern.err kernel: [atbm_log]:atbm_set_uapsd_param:uapsdFlags(0)
Sep 2 23:18:06 gk7205v210-imx307 kern.err kernel: [atbm_log]:atbm_set_uapsd_param:uapsdFlags(0)
Sep 2 23:18:06 gk7205v210-imx307 kern.info kernel: IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Sep 2 23:18:06 gk7205v210-imx307 kern.err kernel: [atbm_log]:__ieee80211_start_scan:channels[14]
Sep 2 23:18:06 gk7205v210-imx307 kern.err kernel: [atbm_log]:ieee80211_prep_hw_scan:n_chans(14),space(14),index(14),scaned(14)
Sep 2 23:18:06 gk7205v210-imx307 kern.err kernel: [atbm_log]:atbm_hw_scan:if_id(0)
Sep 2 23:18:06 gk7205v210-imx307 kern.err kernel: [atbm_log]:atbm_hw_scan:scan, delay suspend
Sep 2 23:18:06 gk7205v210-imx307 kern.err kernel: [atbm_log]:scan start band(0),(14)
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:hw_priv->scan.status 0
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:atbm_scan_work:end(0)
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:stop scan:policy empty
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:wlan0:free authen bss ++
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:authen:(50:ff:20:a7:13:55),ssid(Andriano)
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:authenticate[50:ff:20:a7:13:55]:[0][1]
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:wlan0: authenticate with 50:ff:20:a7:13:55 (try 1) (1)(0)
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:[STA] Join DTIM: 1, interval: 100
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:atbm_set_pm:if_id(0) is not assco
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:[TX]:authen, delay suspend
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:cancle_work_done:[50:ff:20:a7:13:55][15][11]
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:wlan0: authenticated
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:work:flush sta[50:ff:20:a7:13:55]
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:wlan0:free authen bss ++
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:wlan0:free authen bss --
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:work:flush sta[50:ff:20:a7:13:55]
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:sta has been insert(0)
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:cancle_work_done:[50:ff:20:a7:13:55][15][11]
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:flush sta(0):
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:wlan0: associated
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:wlan0:free authen bss ++
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:atbm_set_uapsd_param:uapsdFlags(0)
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:atbm_set_uapsd_param:uapsdFlags(0)
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:atbm_set_uapsd_param:uapsdFlags(0)
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:atbm_set_uapsd_param:uapsdFlags(0)
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:[50:ff:20:a7:13:55]:20M channel
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:atbm_bss_info_changed:chatype(1),channelNumber(5)
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:[wlan0] Waiting Txq Ready[1]
Sep 2 23:18:07 gk7205v210-imx307 kern.info kernel: IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:[50:ff:20:a7:13:55]:assc sucess band[0]
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:ieee80211_recalc_ps:work busy
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:[wlan0]:dtim changed [0]->[1]
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:[wlan0]:[8e88] deliver slow
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:[wlan0]:down_eap_rate
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:wlan0:2/4 Pairwise
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:[wlan0]:[8e88] deliver slow
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:[wlan0]:down_eap_rate
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:wlan0:4/4 Pairwise
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:^A3SET_KEY:idx(0),if_id(0)
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:^A3SET_KEY:idx(1),if_id(0)
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:ieee80211_recalc_ps:work busy
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:KEK[40][39][99][34]
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:KCK[31][0][24][16]
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:AMPDU[wlan0]:action[2],tid[0],ssn[1],buff_size[0],token[0],ta[50:ff:20:a7:13:55]
Sep 2 23:18:07 gk7205v210-imx307 kern.err kernel: [atbm_log]:AMPDU[wlan0]:action[4],tid[0],ssn[0],buff_size[64],token[0],ta[50:ff:20:a7:13:55]
Sep 2 23:18:08 gk7205v210-imx307 kern.err kernel: [atbm_log]:[wlan0]:[8] deliver slow
Sep 2 23:18:08 gk7205v210-imx307 kern.err kernel: [atbm_log]:ieee80211_process_addba_request:mac[50:ff:20:a7:13:55],tid[0]
Sep 2 23:18:08 gk7205v210-imx307 kern.err kernel: [atbm_log]:AMPDU[wlan0]:action[0],tid[0],ssn[3],buff_size[0],token[0],ta[50:ff:20:a7:13:55]
Sep 2 23:18:08 gk7205v210-imx307 kern.emerg kernel: rx ampdu ++
Sep 2 23:18:09 gk7205v210-imx307 kern.err kernel: [atbm_log]:[wlan0]:[8] deliver slow
Sep 2 23:18:09 gk7205v210-imx307 kern.err kernel: [atbm_log]:connecting done
Sep 2 23:18:11 gk7205v210-imx307 kern.err kernel: [atbm_log]:start tx ba session fail[50:ff:20:a7:13:55][2]
Sep 2 23:18:11 gk7205v210-imx307 kern.err kernel: [atbm_log]:start tx ba session fail[50:ff:20:a7:13:55][2]
Sep 2 23:18:11 gk7205v210-imx307 kern.err kernel: [atbm_log]:start tx ba session fail[50:ff:20:a7:13:55][2]
Sep 2 23:18:11 gk7205v210-imx307 kern.err kernel: [atbm_log]:AMPDU[wlan0]:action[2],tid[2],ssn[4],buff_size[0],token[1],ta[50:ff:20:a7:13:55]
Sep 2 23:18:11 gk7205v210-imx307 kern.err kernel: [atbm_log]:AMPDU[wlan0]:action[4],tid[2],ssn[0],buff_size[64],token[1],ta[50:ff:20:a7:13:55]
Sep 2 23:18:12 gk7205v210-imx307 kern.err kernel: [atbm_log]:ieee80211_process_addba_request:mac[50:ff:20:a7:13:55],tid[5]
Sep 2 23:18:12 gk7205v210-imx307 kern.err kernel: [atbm_log]:AMPDU[wlan0]:action[0],tid[5],ssn[1],buff_size[0],token[1],ta[50:ff:20:a7:13:55]
Sep 2 23:18:33 gk7205v210-imx307 kern.err kernel: [atbm_log]:AMPDU[wlan0]:action[2],tid[6],ssn[1],buff_size[0],token[2],ta[50:ff:20:a7:13:55]
Sep 2 23:18:33 gk7205v210-imx307 kern.err kernel: [atbm_log]:AMPDU[wlan0]:action[4],tid[6],ssn[0],buff_size[64],token[2],ta[50:ff:20:a7:13:55]
Sep 2 23:18:33 gk7205v210-imx307 kern.info kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
Sep 2 23:18:33 gk7205v210-imx307 authpriv.info dropbear[770]: Running in background
Sep 2 23:18:33 gk7205v210-imx307 cron.info crond[772]: crond (busybox 1.36.1) started, log level 8
Sep 2 23:18:33 gk7205v210-imx307 kern.info kernel: hisi-hwrng: TRNG at 0x10080000+0x204 registered (pump)
Sep 2 23:18:33 gk7205v210-imx307 daemon.info goke: SENSOR: imx307
Sep 2 23:18:33 gk7205v210-imx307 kern.emerg kernel: ==== online_flag=0, cmos_yuv_flag=0, sensor=imx307, chip=gk7205v200, board=demo====
Sep 2 23:18:33 gk7205v210-imx307 kern.emerg kernel: ==== g_quick_start_flag=0 ====
Sep 2 23:18:33 gk7205v210-imx307 kern.emerg kernel: sysconfig init success!
Sep 2 23:18:33 gk7205v210-imx307 kern.emerg kernel: Module media: init ok
Sep 2 23:18:33 gk7205v210-imx307 kern.info kernel: Media Memory Zone Manager
Sep 2 23:18:33 gk7205v210-imx307 kern.emerg kernel: osal 1.0 init success!
Sep 2 23:18:33 gk7205v210-imx307 kern.emerg kernel: load sys.ko OK!
Sep 2 23:18:33 gk7205v210-imx307 kern.emerg kernel: load region.ko OK!
Sep 2 23:18:33 gk7205v210-imx307 kern.emerg kernel: load vgs.ko OK!
Sep 2 23:18:33 gk7205v210-imx307 kern.emerg kernel: load vi.ko OK !
Sep 2 23:18:33 gk7205v210-imx307 kern.info kernel: openipc_frame_ts: /dev/openipc-frame-ts minor=57, event types=2, ring_depth=256
Sep 2 23:18:33 gk7205v210-imx307 kern.emerg kernel: ISP Mod init!
Sep 2 23:18:33 gk7205v210-imx307 kern.emerg kernel: load vpss.ko OK!
Sep 2 23:18:33 gk7205v210-imx307 kern.emerg kernel: load chnl.ko OK!
Sep 2 23:18:33 gk7205v210-imx307 kern.emerg kernel: load vedu.ko OK!
Sep 2 23:18:33 gk7205v210-imx307 kern.emerg kernel: load rc.ko OK!
Sep 2 23:18:33 gk7205v210-imx307 kern.emerg kernel: load venc.ko OK!
Sep 2 23:18:33 gk7205v210-imx307 kern.emerg kernel: load h264e.ko OK!
Sep 2 23:18:34 gk7205v210-imx307 kern.emerg kernel: load h265e.ko OK!
Sep 2 23:18:34 gk7205v210-imx307 kern.emerg kernel: load jpege.ko OK!
Sep 2 23:18:34 gk7205v210-imx307 kern.emerg kernel: load ive.ko OK!
Sep 2 23:18:34 gk7205v210-imx307 kern.emerg kernel: Load sensor_spi.ko OK !
Sep 2 23:18:34 gk7205v210-imx307 kern.emerg kernel: load mipi_rx driver successful!
Sep 2 23:18:34 gk7205v210-imx307 kern.emerg kernel: register dev
Sep 2 23:18:34 gk7205v210-imx307 kern.emerg kernel: Watchdog Timer: 0.01 initialized. default_margin=60 sec (nodeamon= 0)
Sep 2 23:18:34 gk7205v210-imx307 kern.emerg kernel: wtdg init ok. ver=Sep 1 2026, 23:42:38.
Sep 2 23:18:34 gk7205v210-imx307 kern.emerg kernel: Load hi_cipher.ko success.
Sep 2 23:18:34 gk7205v210-imx307 daemon.info : starting pid 935, tty '/dev/console': '/sbin/getty -L console 0 vt100'
Sep 2 23:18:35 gk7205v210-imx307 user.info majestic[928]: Majestic Lite for HiSilicon (gk7205v200), version master+8d7c8b1, built on 2026-09-01 17:54
Sep 2 23:18:36 gk7205v210-imx307 user.debug majestic[928]: Main audio codec is aac (other options: opus, pcm, alaw, ulaw)
Sep 2 23:18:36 gk7205v210-imx307 user.info majestic[928]: Loading main configuration: /etc/majestic.yaml
Sep 2 23:18:36 gk7205v210-imx307 user.debug majestic[928]: Detected Watchdog
Sep 2 23:18:36 gk7205v210-imx307 user.debug majestic[928]: Watchdog timeout set to 300 seconds
Sep 2 23:18:36 gk7205v210-imx307 user.debug majestic[928]: Set server path: /var/www
Sep 2 23:18:36 gk7205v210-imx307 user.info majestic[928]: HTTP server started on :::80
Sep 2 23:18:36 gk7205v210-imx307 user.warn majestic[928]: HTTPS port :::443 configured without cert/key; skipping TLS server
Sep 2 23:18:36 gk7205v210-imx307 user.info majestic[928]: Using /etc/sensors/imx307_i2c_2l_1080p_30fps.ini sensor configuration file
Sep 2 23:18:36 gk7205v210-imx307 user.debug majestic[928]: App was built with MPP version: Gk7205V200_MPP_V1.0.1.0.B020 Release
Sep 2 23:18:36 gk7205v210-imx307 user.debug majestic[928]: Current MPP version: VERSION=MPP_V1.0.1.0 B020 Release
Sep 2 23:18:36 gk7205v210-imx307 user.info majestic[928]: VB sizing: 3 blocks for the pipeline (0 of them held by the VI path), default 4, isp.blkCnt 4 in effect
Sep 2 23:18:36 gk7205v210-imx307 user.debug majestic[928]: sensor stSnsImx307_2l_Obj
Sep 2 23:18:36 gk7205v210-imx307 user.debug majestic[928]: input_mode MIPI, WDR NONE
Sep 2 23:18:36 gk7205v210-imx307 user.debug majestic[928]: dev [1920x1080]@200x20 30fps, RGGB
Sep 2 23:18:36 gk7205v210-imx307 user.debug majestic[928]: trying to load /usr/lib/sensors/libsns_imx307_2l.so
Sep 2 23:18:36 gk7205v210-imx307 user.debug majestic[928]: Free MMZ mem before allocation: 32476KB
Sep 2 23:18:36 gk7205v210-imx307 user.debug majestic[928]: VB configuration:
Sep 2 23:18:36 gk7205v210-imx307 user.debug majestic[928]: [0]: 3110400 x 3
Sep 2 23:18:36 gk7205v210-imx307 user.debug majestic[928]: [1]: 3110400 x 1
Sep 2 23:18:36 gk7205v210-imx307 user.debug majestic[928]: Free MMZ mem after allocation: 32476KB
Sep 2 23:18:36 gk7205v210-imx307 user.info majestic[928]: SET_DEV_ATTR: devno=0 input_mode=0 data_rate=0 img_rect={0,0,1920,1080} data_type=2 wdr=0 lanes=[0,2,-1,-1]
Sep 2 23:18:36 gk7205v210-imx307 user.debug majestic[928]: Setting VI-VPSS mode: pipe0=3 (vi_online=1 vpss_online=1)
Sep 2 23:18:36 gk7205v210-imx307 user.debug majestic[928]: Sensor driver loaded
Sep 2 23:18:36 gk7205v210-imx307 user.debug majestic[928]: SDK is in 'VI_ONLINE_VPSS_ONLINE' mode
Sep 2 23:18:36 gk7205v210-imx307 user.debug majestic[928]: IntType=2 EarlyLine=128 LowDelay=0 LineCnt=128
Sep 2 23:18:36 gk7205v210-imx307 user.info majestic[928]: linear mode
Sep 2 23:18:36 gk7205v210-imx307 user.info majestic[928]: ==============================================================
Sep 2 23:18:36 gk7205v210-imx307 user.info majestic[928]: =====Sony imx307_2l sensor 1080P30fps(MIPI) init success!=====
Sep 2 23:18:36 gk7205v210-imx307 user.info majestic[928]: ==============================================================
Sep 2 23:18:36 gk7205v210-imx307 user.debug majestic[928]: Exposure: 100ms (10fps), aGain: 32768, dGain: 1024, ispGain: 1024, mode: slow_shutter
Sep 2 23:18:36 gk7205v210-imx307 user.debug majestic[928]: BE AF statistics enabled: 17x15 zones over 1920x1080, YUV domain
Sep 2 23:18:36 gk7205v210-imx307 user.debug majestic[928]: SoC reports 3 VENC channels
Sep 2 23:18:36 gk7205v210-imx307 user.info majestic[928]: Loading IQ profile /etc/sensors/iq/default.ini
Sep 2 23:18:36 gk7205v210-imx307 user.info majestic[928]: Loading INI profile /etc/sensors/iq/default.ini
Sep 2 23:18:36 gk7205v210-imx307 user.debug majestic[928]: h265 1920x1080@25fps 4096kbit 25gop
Sep 2 23:18:36 gk7205v210-imx307 user.debug majestic[928]: venc_chn: 0, vpss_grp: 0, vpss_chn: 0
Sep 2 23:18:36 gk7205v210-imx307 user.info majestic[928]: vpss chn 0 compression: asked none, kept none
Sep 2 23:18:36 gk7205v210-imx307 user.debug majestic[928]: minQp: 28, maxQp: 42
Sep 2 23:18:36 gk7205v210-imx307 user.debug majestic[928]: venc took 4716KB of MMZ [1012]
Sep 2 23:18:36 gk7205v210-imx307 user.debug majestic[928]: Audio took 128KB of MMZ
Sep 2 23:18:36 gk7205v210-imx307 user.debug majestic[928]: HiSilicon SDK started
Sep 2 23:18:36 gk7205v210-imx307 user.debug majestic[928]: Free MMZ mem finally: 12968KB
Sep 2 23:18:36 gk7205v210-imx307 user.info majestic[928]: onvif discovery sent Hello via eth0
Sep 2 23:18:36 gk7205v210-imx307 user.info majestic[928]: also answering for gk7205v210-imx307.local.
Sep 2 23:18:36 gk7205v210-imx307 user.info majestic[928]: RTSP server started on port 554
Sep 2 23:18:36 gk7205v210-imx307 user.debug majestic[928]: DTLS identity: P-256, 293-byte certificate
Sep 2 23:18:36 gk7205v210-imx307 user.info majestic[928]: WebRTC fingerprint sha-256 8B:16:11:94:25:10:11:C8:91:35:BD:1C:02:64:08:AE:60:CC:4D:E0:4C:7F:D3:73:F1:F8:55:03:82:2C:9A:34
Sep 2 23:18:36 gk7205v210-imx307 user.debug majestic[928]: set_gpio(9, 0)
Sep 2 23:18:36 gk7205v210-imx307 user.debug majestic[928]: set_gpio(8, 1)
Sep 2 23:18:36 gk7205v210-imx307 user.debug majestic[928]: set_gpio(4, 0)
Sep 2 23:18:36 gk7205v210-imx307 user.info majestic[928]: Connecting: rtmp://a.rtmp.youtube.com/live2/xxxxxxxxxxxxxxx
Sep 2 23:18:36 gk7205v210-imx307 user.debug majestic[928]: set_gpio(9, 0)
Sep 2 23:18:36 gk7205v210-imx307 user.debug majestic[928]: set_gpio(8, 0)
Sep 2 23:18:38 gk7205v210-imx307 user.info majestic[928]: onvif discovery sent Probe via eth0
Sep 2 23:18:40 gk7205v210-imx307 auth.info login[935]: root login on 'console'
Sep 2 23:18:49 gk7205v210-imx307 user.info majestic[928]: session restored from stay-signed-in token for root
Sep 2 23:18:49 gk7205v210-imx307 user.debug majestic[928]: MJPEG 1920x1080@5fps 50q
Sep 2 23:18:49 gk7205v210-imx307 user.debug majestic[928]: venc_chn: 1, vpss_grp: 0, vpss_chn: 1
Sep 2 23:18:49 gk7205v210-imx307 user.info majestic[928]: vpss chn 1 compression: asked none, kept none
Sep 2 23:18:49 gk7205v210-imx307 user.debug majestic[928]: mpeg_enc took 2048KB of MMZ [2040]
Sep 2 23:18:49 gk7205v210-imx307 user.debug majestic[928]: MJPEG channel raised
Sep 2 23:18:49 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:18:53 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:19:03 gk7205v210-imx307 user.debug majestic[928]: Stopped 1 channel
Sep 2 23:19:03 gk7205v210-imx307 user.debug majestic[928]: MJPEG channel dropped
Sep 2 23:19:03 gk7205v210-imx307 user.debug majestic[928]: MJPEG 1920x1080@5fps 50q
Sep 2 23:19:03 gk7205v210-imx307 user.debug majestic[928]: venc_chn: 1, vpss_grp: 0, vpss_chn: 1
Sep 2 23:19:03 gk7205v210-imx307 user.info majestic[928]: vpss chn 1 compression: asked none, kept none
Sep 2 23:19:03 gk7205v210-imx307 user.debug majestic[928]: mpeg_enc took 2048KB of MMZ [2040]
Sep 2 23:19:03 gk7205v210-imx307 user.debug majestic[928]: MJPEG channel raised
Sep 2 23:19:03 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:19:08 gk7205v210-imx307 user.info majestic[928]: onvif discovery sent Probe via eth0
Sep 2 23:19:13 gk7205v210-imx307 user.debug majestic[928]: Stopped 1 channel
Sep 2 23:19:13 gk7205v210-imx307 user.debug majestic[928]: MJPEG channel dropped
Sep 2 23:19:23 gk7205v210-imx307 user.debug majestic[928]: MJPEG 1920x1080@5fps 50q
Sep 2 23:19:23 gk7205v210-imx307 user.debug majestic[928]: venc_chn: 1, vpss_grp: 0, vpss_chn: 1
Sep 2 23:19:23 gk7205v210-imx307 user.info majestic[928]: vpss chn 1 compression: asked none, kept none
Sep 2 23:19:23 gk7205v210-imx307 user.debug majestic[928]: mpeg_enc took 2048KB of MMZ [2040]
Sep 2 23:19:23 gk7205v210-imx307 user.debug majestic[928]: MJPEG channel raised
Sep 2 23:19:23 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:19:28 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:19:31 gk7205v210-imx307 user.info majestic[928]: found urn:uuid:283e679c-c6b2-11ed-911a-ad5b565b6668 at 192.168.1.108
Sep 2 23:19:38 gk7205v210-imx307 user.info majestic[928]: onvif discovery sent Probe via eth0
Sep 2 23:19:38 gk7205v210-imx307 user.debug majestic[928]: Stopped 1 channel
Sep 2 23:19:38 gk7205v210-imx307 user.debug majestic[928]: MJPEG channel dropped
Sep 2 23:20:08 gk7205v210-imx307 user.info majestic[928]: onvif discovery sent Probe via eth0
Sep 2 23:20:08 gk7205v210-imx307 user.debug majestic[928]: MJPEG 1920x1080@5fps 50q
Sep 2 23:20:08 gk7205v210-imx307 user.debug majestic[928]: venc_chn: 1, vpss_grp: 0, vpss_chn: 1
Sep 2 23:20:08 gk7205v210-imx307 user.info majestic[928]: vpss chn 1 compression: asked none, kept none
Sep 2 23:20:08 gk7205v210-imx307 user.debug majestic[928]: mpeg_enc took 2048KB of MMZ [2040]
Sep 2 23:20:08 gk7205v210-imx307 user.debug majestic[928]: MJPEG channel raised
Sep 2 23:20:08 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:20:18 gk7205v210-imx307 user.debug majestic[928]: Stopped 1 channel
Sep 2 23:20:18 gk7205v210-imx307 user.debug majestic[928]: MJPEG channel dropped
Sep 2 23:20:38 gk7205v210-imx307 user.debug majestic[928]: MJPEG 1920x1080@5fps 50q
Sep 2 23:20:38 gk7205v210-imx307 user.debug majestic[928]: venc_chn: 1, vpss_grp: 0, vpss_chn: 1
Sep 2 23:20:38 gk7205v210-imx307 user.info majestic[928]: vpss chn 1 compression: asked none, kept none
Sep 2 23:20:38 gk7205v210-imx307 user.debug majestic[928]: mpeg_enc took 2048KB of MMZ [2040]
Sep 2 23:20:38 gk7205v210-imx307 user.debug majestic[928]: MJPEG channel raised
Sep 2 23:20:38 gk7205v210-imx307 user.info majestic[928]: onvif discovery sent Probe via eth0
Sep 2 23:20:38 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:20:43 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:20:48 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:20:53 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:20:58 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:21:03 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:21:08 gk7205v210-imx307 user.info majestic[928]: onvif discovery sent Probe via eth0
Sep 2 23:21:08 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:21:13 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:21:18 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:21:23 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:21:28 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:21:33 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:21:38 gk7205v210-imx307 user.info majestic[928]: onvif discovery sent Probe via eth0
Sep 2 23:21:38 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:21:43 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:21:48 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:21:53 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:21:58 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:22:03 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:22:08 gk7205v210-imx307 user.info majestic[928]: onvif discovery sent Probe via eth0
Sep 2 23:22:08 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:22:13 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:22:18 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:22:23 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:22:28 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:22:33 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:22:38 gk7205v210-imx307 user.info majestic[928]: onvif discovery sent Probe via eth0
Sep 2 23:22:38 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:22:46 gk7205v210-imx307 user.debug majestic[928]: Native WebRTC client 0xb668c650 connected
Sep 2 23:22:46 gk7205v210-imx307 user.err majestic[928]: no usable video codec in the offer; the peer offered 8 codec(s):
Sep 2 23:22:46 gk7205v210-imx307 user.err majestic[928]: pt 102 H.264 profile-level-id 42001f packetization-mode 1 level-asymmetry-allowed
Sep 2 23:22:46 gk7205v210-imx307 user.err majestic[928]: pt 104 H.264 profile-level-id 42001f packetization-mode 0 level-asymmetry-allowed
Sep 2 23:22:46 gk7205v210-imx307 user.err majestic[928]: pt 108 H.264 profile-level-id 42e01f packetization-mode 1 level-asymmetry-allowed
Sep 2 23:22:46 gk7205v210-imx307 user.err majestic[928]: pt 114 H.264 profile-level-id 42e01f packetization-mode 0 level-asymmetry-allowed
Sep 2 23:22:46 gk7205v210-imx307 user.err majestic[928]: pt 116 H.264 profile-level-id 4d001f packetization-mode 1 level-asymmetry-allowed
Sep 2 23:22:46 gk7205v210-imx307 user.err majestic[928]: pt 39 H.264 profile-level-id 4d001f packetization-mode 0 level-asymmetry-allowed
Sep 2 23:22:46 gk7205v210-imx307 user.err majestic[928]: pt 41 H.264 profile-level-id f4001f packetization-mode 1 level-asymmetry-allowed
Sep 2 23:22:46 gk7205v210-imx307 user.err majestic[928]: pt 43 H.264 profile-level-id f4001f packetization-mode 0 level-asymmetry-allowed
Sep 2 23:22:46 gk7205v210-imx307 user.err majestic[928]: video0 encodes H.265 profile-id 1 tier 0 level-id 123; video0.size drives the level, the profile is Main and cannot be changed, and video0.codec h264 is what serves a peer that cannot take HEVC
Sep 2 23:22:46 gk7205v210-imx307 user.err majestic[928]: Nothing this camera encodes is something the peer can decode
Sep 2 23:22:46 gk7205v210-imx307 user.debug majestic[928]: Native WebRTC client 0xb668d450 connected
Sep 2 23:22:46 gk7205v210-imx307 user.debug majestic[928]: Native WebRTC client 0xb668d450 disconnected
Sep 2 23:22:46 gk7205v210-imx307 user.debug majestic[928]: Native WebRTC client 0xb668c650 disconnected
Sep 2 23:23:05 gk7205v210-imx307 authpriv.info dropbear[2077]: Child connection from 192.168.1.112:57020
Sep 2 23:23:15 gk7205v210-imx307 authpriv.notice dropbear[2077]: Password auth succeeded for 'root' from 192.168.1.112:57020
Sep 2 23:23:20 gk7205v210-imx307 user.err majestic[928]: WriteN, RTMP send error 32 (700 bytes)
Sep 2 23:23:23 gk7205v210-imx307 user.err majestic[928]: WriteN, RTMP send error 32 (59 bytes)
Sep 2 23:23:24 gk7205v210-imx307 user.err majestic[928]: WriteN, RTMP send error 9 (42 bytes)
Sep 2 23:23:25 gk7205v210-imx307 user.warn majestic[928]: Connection failed, reconnect [0] in 10 seconds
Sep 2 23:23:25 gk7205v210-imx307 user.info majestic[928]: onvif discovery sent Probe via eth0
Sep 2 23:23:25 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:23:30 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:23:35 gk7205v210-imx307 user.info majestic[928]: Connecting: rtmp://a.rtmp.youtube.com/live2/xxxxxxxxxxxxxx
Sep 2 23:23:35 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:23:40 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:23:45 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:23:50 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:23:55 gk7205v210-imx307 user.info majestic[928]: onvif discovery sent Probe via eth0
Sep 2 23:23:55 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:24:00 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:24:05 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:24:10 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:24:15 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:24:20 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:24:25 gk7205v210-imx307 user.info majestic[928]: onvif discovery sent Probe via eth0
Sep 2 23:24:25 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:24:30 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:24:35 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:24:40 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:24:45 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:24:50 gk7205v210-imx307 user.debug majestic[928]: JPEG was sent to client
Sep 2 23:24:55 gk7205v210-imx307 user.info majestic[928]: onvif discovery sent Probe via eth0
Sep 2 23:25:00 gk7205v210-imx307 user.debug majestic[928]: Stopped 1 channel
Sep 2 23:25:00 gk7205v210-imx307 user.debug majestic[928]: MJPEG channel dropped
Sep 2 23:25:25 gk7205v210-imx307 user.info majestic[928]: onvif discovery sent Probe via eth0
Sep 2 23:25:55 gk7205v210-imx307 user.info majestic[928]: onvif discovery sent Probe via eth0
Sep 2 23:26:25 gk7205v210-imx307 user.info majestic[928]: onvif discovery sent Probe via eth0
Sep 2 23:26:55 gk7205v210-imx307 user.info majestic[928]: onvif discovery sent Probe via eth0
Sep 2 23:27:25 gk7205v210-imx307 user.info majestic[928]: onvif discovery sent Probe via eth0
Sep 2 23:27:56 gk7205v210-imx307 user.info majestic[928]: onvif discovery sent Probe via eth0
Sep 2 23:28:28 gk7205v210-imx307 user.info majestic[928]: onvif discovery sent Probe via eth0
Sep 2 23:28:57 gk7205v210-imx307 user.info majestic[928]: onvif discovery sent Probe via eth0

Thank you — the LAN comparison and the second capture were exactly what was needed, and they let us take this off you and onto our own bench. We have now reproduced your setup as closely as we can in the lab. The short version: we could not make this happen with our hardware, and your own numbers rule out the camera software. Details below, because the negative result is the useful part.

What your log settles

Socket memory is not the consumer. Across your whole run, TCP: ... mem peaks at 51 — and that field is in pages, so 204 kB — while orphan never leaves 0. Nothing is accumulating in the network stack's own accounting. That was our main suspect and it is dead.

The memory is going somewhere /proc/meminfo does not report. Adding up everything your samples do account for — free + buffers + cached + anonymous + slab + page tables — against MemTotal: 27336 kB:

time	accounted	unaccounted
23:18:44	18900 kB	8436 kB
23:20:46	15084 kB	12252 kB
23:22:51	12180 kB	15156 kB

That is 6.7 MB in four minutes — 27 kB/s, steady, no plateau — while anonymous memory, slab and shared memory all stay flat and the camera's own RSS falls from 5736 kB to 4004 kB. Nothing is being freed; the kernel is evicting clean pages it can re-read later, which on this camera means program text stored on flash. Once those are gone every call has to fault them back off the chip, and that is the lag you see at 90%. The figure in the web interface is (MemTotal − MemAvailable) / MemTotal, so it climbs from 64% to 92% while the streamer's own footprint is going down.

A correction to the script we gave you. It sampled VmallocUsed, and yours reads 0 kB in all nine samples. That is not a measurement — the field was deliberately stubbed to a constant zero in Linux 4.4 and only regained meaning in 5.9. Your kernel is 4.9.37, so it says nothing, and we should not have included it. The replacement below reads the real source instead.

What we did on our bench

We put a USB Wi-Fi dongle on a lab camera with the same SoC family, the same 4.9.37 kernel, the same missing CMA zone, and the same IMX307 sensor, and matched your configuration down to the codec, resolution, frame rate, bitrate, one-second GOP and QP limits. Three runs, sampling the unaccounted figure above every 30 seconds:

run	condition	pushed over Wi-Fi	unaccounted memory
A	streamer stopped, link saturated	3238 MB	flat (ended 232 kB below start)
B	streamer publishing RTMP, VBR	17 MB	flat, no trend over 22 samples
C	streamer publishing RTMP, CBR	165 MB	flat, no trend over 22 samples

Run A moved 26 times the data your camera moved during its four-minute climb, with the streamer not even running, and lost nothing. Run C moved more bytes than your leak window did, with the streamer running, and lost nothing. Throughout, our camera's RSS moved by 28 kB and its thread count did not change.

So the general explanation — "USB Wi-Fi on a small no-CMA 4.9 camera leaks under load" — is not true. It does not happen on this board class.

What that leaves

The one thing our bench could not copy is your Wi-Fi driver. Your boot log shows an out-of-tree vendor module, atbm6012b_wifi_usb for an AltoBeam ATBM6012B, which prints not CONFIG_USE_DMA_ADDR_BUFFER when it starts — it allocates transfer buffers per transfer rather than reusing a fixed pool. We used a Realtek adapter, because that is what we have. Everything else was the same.

Your board also has 8 MB less RAM than ours, which changes how quickly you notice the problem but cannot create the allocation.

We are not declaring your driver guilty from here. But it is now the only variable left, and there are two cheap ways to settle it.

1. Run the same test we ran, on your camera. Reboot, stop the streamer, and push traffic with nothing else running:

# on your PC:      nc -l -p 5001 > /dev/null
killall majestic
sleep 5
( while :; do date -Iseconds; cat /proc/meminfo; echo ---; sleep 30; done ) > /tmp/mem311c.log 2>&1 &
dd if=/dev/zero bs=64k | nc <your-pc-ip> 5001
# let it run five minutes, Ctrl-C, and post /tmp/mem311c.log

If the unaccounted figure climbs with the streamer stopped, that is proof, and we will help you take it to the right project with the evidence attached.

2. If you have any other USB Wi-Fi adapter, try it. Different chip, same everything else. That is the whole experiment.

Either way, this sampler reads the fields the last one missed — in particular it summarises /proc/vmallocinfo by caller, which names the module responsible if the allocation goes through vmalloc:

( while :; do
    date -Iseconds
    cat /proc/meminfo
    cat /proc/buddyinfo
    grep -E 'wlan0|eth0' /proc/net/dev
    awk '{split($3,a,"+"); s[a[1]]+=$2} END {for (k in s) printf "  vmalloc %10d B  %s\n", s[k], k}' \
        /proc/vmallocinfo | sort -k2 -rn | head -10
    awk '/^(Threads|VmRSS):/{print}' /proc/$(pidof majestic)/status 2>/dev/null
    echo ---
    sleep 30
  done ) > /tmp/mem311d.log 2>&1 &

Our own bug, which is real and separate

Toggling outgoing.substream changed nothing for you, and that is exactly what we expected once we looked: the outgoing stream only follows that setting when the second stream is also enabled. Yours is disabled, so the camera silently publishes the main stream instead — 1920×1080 H.265 at 4096 kbit/s, roughly four times what your configuration asks for, across the link that is misbehaving. Your boot log confirms it: only the 1080p encoder is ever configured.

A camera that quietly publishes something other than its configuration is our problem, and it will be made to say so.

Until that ships, the workaround is likely to help you today whatever the driver turns out to be doing: enable the second stream and leave the substream option on. The outgoing stream then really is 640×360 H.264 at 1024 kbit/s and the traffic across the Wi-Fi drops by roughly a factor of four. Since you describe the growth as scaling with stream intensity, that alone may keep the camera below the point where it starts to struggle.

Separately, your build is from 1 September and a fix for a stalled outgoing connection landed on the 2nd. Your log does show the connection erroring out and reconnecting, so a current nightly is worth taking — though we do not expect it to change the memory picture and we are not treating this report as solved by it.

Leaving this open.

Settings: a field the camera is quietly overriding says so

Unfortunately, I don't have another Wi-Fi adapter for testing. But for your information, the exact same adapter works perfectly on a camera with GK7205V300 + IMX335 And yes, it also uses the vixand firmware gk7205v300_lite_vixand-ivg-g6s-w.
Below are the results of the test you requested:

cat /tmp/mem311c.log
2026-09-03T21:11:23+03:00
MemTotal: 27336 kB
MemFree: 3940 kB
MemAvailable: 12240 kB
Buffers: 3520 kB
Cached: 5880 kB
SwapCached: 0 kB
Active: 5504 kB
Inactive: 4528 kB
Active(anon): 640 kB
Inactive(anon): 88 kB
Active(file): 4864 kB
Inactive(file): 4440 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 652 kB
Mapped: 1720 kB
Shmem: 96 kB
Slab: 5344 kB
SReclaimable: 1600 kB
SUnreclaim: 3744 kB
KernelStack: 640 kB
PageTables: 196 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 13668 kB
Committed_AS: 2536 kB
VmallocTotal: 999424 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
CmaTotal: 0 kB
CmaFree: 0 kB

2026-09-03T21:11:53+03:00
MemTotal: 27336 kB
MemFree: 3348 kB
MemAvailable: 11672 kB
Buffers: 3520 kB
Cached: 5904 kB
SwapCached: 0 kB
Active: 5668 kB
Inactive: 4516 kB
Active(anon): 772 kB
Inactive(anon): 84 kB
Active(file): 4896 kB
Inactive(file): 4432 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 780 kB
Mapped: 1720 kB
Shmem: 96 kB
Slab: 5372 kB
SReclaimable: 1600 kB
SUnreclaim: 3772 kB
KernelStack: 656 kB
PageTables: 240 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 13668 kB
Committed_AS: 2912 kB
VmallocTotal: 999424 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
CmaTotal: 0 kB
CmaFree: 0 kB

2026-09-03T21:12:23+03:00
MemTotal: 27336 kB
MemFree: 3336 kB
MemAvailable: 11660 kB
Buffers: 3520 kB
Cached: 5904 kB
SwapCached: 0 kB
Active: 5668 kB
Inactive: 4516 kB
Active(anon): 772 kB
Inactive(anon): 84 kB
Active(file): 4896 kB
Inactive(file): 4432 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 780 kB
Mapped: 1720 kB
Shmem: 96 kB
Slab: 5388 kB
SReclaimable: 1600 kB
SUnreclaim: 3788 kB
KernelStack: 656 kB
PageTables: 236 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 13668 kB
Committed_AS: 2912 kB
VmallocTotal: 999424 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
CmaTotal: 0 kB
CmaFree: 0 kB

2026-09-03T21:12:53+03:00
MemTotal: 27336 kB
MemFree: 3292 kB
MemAvailable: 11620 kB
Buffers: 3520 kB
Cached: 5908 kB
SwapCached: 0 kB
Active: 5676 kB
Inactive: 4512 kB
Active(anon): 772 kB
Inactive(anon): 84 kB
Active(file): 4904 kB
Inactive(file): 4428 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 780 kB
Mapped: 1720 kB
Shmem: 96 kB
Slab: 5392 kB
SReclaimable: 1600 kB
SUnreclaim: 3792 kB
KernelStack: 656 kB
PageTables: 240 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 13668 kB
Committed_AS: 2912 kB
VmallocTotal: 999424 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
CmaTotal: 0 kB
CmaFree: 0 kB

2026-09-03T21:13:23+03:00
MemTotal: 27336 kB
MemFree: 3288 kB
MemAvailable: 11620 kB
Buffers: 3520 kB
Cached: 5912 kB
SwapCached: 0 kB
Active: 5680 kB
Inactive: 4512 kB
Active(anon): 776 kB
Inactive(anon): 84 kB
Active(file): 4904 kB
Inactive(file): 4428 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 780 kB
Mapped: 1720 kB
Shmem: 100 kB
Slab: 5396 kB
SReclaimable: 1604 kB
SUnreclaim: 3792 kB
KernelStack: 656 kB
PageTables: 236 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 13668 kB
Committed_AS: 2916 kB
VmallocTotal: 999424 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
CmaTotal: 0 kB
CmaFree: 0 kB

2026-09-03T21:13:53+03:00
MemTotal: 27336 kB
MemFree: 3352 kB
MemAvailable: 11684 kB
Buffers: 3520 kB
Cached: 5912 kB
SwapCached: 0 kB
Active: 5684 kB
Inactive: 4508 kB
Active(anon): 776 kB
Inactive(anon): 84 kB
Active(file): 4908 kB
Inactive(file): 4424 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 780 kB
Mapped: 1720 kB
Shmem: 100 kB
Slab: 5396 kB
SReclaimable: 1604 kB
SUnreclaim: 3792 kB
KernelStack: 656 kB
PageTables: 236 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 13668 kB
Committed_AS: 2916 kB
VmallocTotal: 999424 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
CmaTotal: 0 kB
CmaFree: 0 kB

2026-09-03T21:14:23+03:00
MemTotal: 27336 kB
MemFree: 3400 kB
MemAvailable: 11732 kB
Buffers: 3520 kB
Cached: 5912 kB
SwapCached: 0 kB
Active: 5668 kB
Inactive: 4508 kB
Active(anon): 760 kB
Inactive(anon): 84 kB
Active(file): 4908 kB
Inactive(file): 4424 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 764 kB
Mapped: 1720 kB
Shmem: 100 kB
Slab: 5396 kB
SReclaimable: 1604 kB
SUnreclaim: 3792 kB
KernelStack: 656 kB
PageTables: 236 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 13668 kB
Committed_AS: 2900 kB
VmallocTotal: 999424 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
CmaTotal: 0 kB
CmaFree: 0 kB

2026-09-03T21:14:53+03:00
MemTotal: 27336 kB
MemFree: 3432 kB
MemAvailable: 11764 kB
Buffers: 3520 kB
Cached: 5912 kB
SwapCached: 0 kB
Active: 5668 kB
Inactive: 4508 kB
Active(anon): 760 kB
Inactive(anon): 84 kB
Active(file): 4908 kB
Inactive(file): 4424 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 764 kB
Mapped: 1720 kB
Shmem: 100 kB
Slab: 5396 kB
SReclaimable: 1604 kB
SUnreclaim: 3792 kB
KernelStack: 656 kB
PageTables: 236 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 13668 kB
Committed_AS: 2900 kB
VmallocTotal: 999424 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
CmaTotal: 0 kB
CmaFree: 0 kB

2026-09-03T21:15:23+03:00
MemTotal: 27336 kB
MemFree: 3428 kB
MemAvailable: 11760 kB
Buffers: 3520 kB
Cached: 5916 kB
SwapCached: 0 kB
Active: 5672 kB
Inactive: 4508 kB
Active(anon): 764 kB
Inactive(anon): 84 kB
Active(file): 4908 kB
Inactive(file): 4424 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 764 kB
Mapped: 1720 kB
Shmem: 104 kB
Slab: 5396 kB
SReclaimable: 1604 kB
SUnreclaim: 3792 kB
KernelStack: 656 kB
PageTables: 236 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 13668 kB
Committed_AS: 2904 kB
VmallocTotal: 999424 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
CmaTotal: 0 kB
CmaFree: 0 kB

2026-09-03T21:15:53+03:00
MemTotal: 27336 kB
MemFree: 3368 kB
MemAvailable: 11700 kB
Buffers: 3520 kB
Cached: 5916 kB
SwapCached: 0 kB
Active: 5672 kB
Inactive: 4508 kB
Active(anon): 764 kB
Inactive(anon): 84 kB
Active(file): 4908 kB
Inactive(file): 4424 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 764 kB
Mapped: 1720 kB
Shmem: 104 kB
Slab: 5396 kB
SReclaimable: 1604 kB
SUnreclaim: 3792 kB
KernelStack: 624 kB
PageTables: 232 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 13668 kB
Committed_AS: 2904 kB
VmallocTotal: 999424 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
CmaTotal: 0 kB
CmaFree: 0 kB

2026-09-03T21:16:23+03:00
MemTotal: 27336 kB
MemFree: 3464 kB
MemAvailable: 11796 kB
Buffers: 3520 kB
Cached: 5916 kB
SwapCached: 0 kB
Active: 5672 kB
Inactive: 4508 kB
Active(anon): 764 kB
Inactive(anon): 84 kB
Active(file): 4908 kB
Inactive(file): 4424 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 764 kB
Mapped: 1720 kB
Shmem: 104 kB
Slab: 5396 kB
SReclaimable: 1604 kB
SUnreclaim: 3792 kB
KernelStack: 624 kB
PageTables: 232 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 13668 kB
Committed_AS: 2904 kB
VmallocTotal: 999424 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
CmaTotal: 0 kB
CmaFree: 0 kB

2026-09-03T21:16:53+03:00
MemTotal: 27336 kB
MemFree: 3460 kB
MemAvailable: 11792 kB
Buffers: 3520 kB
Cached: 5916 kB
SwapCached: 0 kB
Active: 5672 kB
Inactive: 4508 kB
Active(anon): 764 kB
Inactive(anon): 84 kB
Active(file): 4908 kB
Inactive(file): 4424 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 764 kB
Mapped: 1720 kB
Shmem: 104 kB
Slab: 5396 kB
SReclaimable: 1604 kB
SUnreclaim: 3792 kB
KernelStack: 624 kB
PageTables: 236 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 13668 kB
Committed_AS: 2904 kB
VmallocTotal: 999424 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
CmaTotal: 0 kB
CmaFree: 0 kB

2026-09-03T21:17:23+03:00
MemTotal: 27336 kB
MemFree: 3444 kB
MemAvailable: 11776 kB
Buffers: 3520 kB
Cached: 5920 kB
SwapCached: 0 kB
Active: 5676 kB
Inactive: 4508 kB
Active(anon): 768 kB
Inactive(anon): 84 kB
Active(file): 4908 kB
Inactive(file): 4424 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 764 kB
Mapped: 1720 kB
Shmem: 108 kB
Slab: 5396 kB
SReclaimable: 1604 kB
SUnreclaim: 3792 kB
KernelStack: 632 kB
PageTables: 240 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 13668 kB
Committed_AS: 2908 kB
VmallocTotal: 999424 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
CmaTotal: 0 kB
CmaFree: 0 kB

2026-09-03T21:17:53+03:00
MemTotal: 27336 kB
MemFree: 3356 kB
MemAvailable: 11688 kB
Buffers: 3520 kB
Cached: 5920 kB
SwapCached: 0 kB
Active: 5676 kB
Inactive: 4508 kB
Active(anon): 768 kB
Inactive(anon): 84 kB
Active(file): 4908 kB
Inactive(file): 4424 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 764 kB
Mapped: 1720 kB
Shmem: 108 kB
Slab: 5396 kB
SReclaimable: 1604 kB
SUnreclaim: 3792 kB
KernelStack: 632 kB
PageTables: 232 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 13668 kB
Committed_AS: 2908 kB
VmallocTotal: 999424 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
CmaTotal: 0 kB
CmaFree: 0 kB

Thank you — that run is useful, and the news about the GK7205V300 is more useful still, though not in the direction you expected. Taking them in turn.

Your test came back flat

Fourteen samples, six and a half minutes, MemTotal unchanged at 27336 kB. The unaccounted figure — the one that climbed at 27 kB/s during the leak:

	unaccounted
sample 1, before the transfer	7804 kB
samples 2–14	8044 – 8204 kB
net change across six minutes	−24 kB

At the rate your camera showed while publishing, that window should have grown by about 9.7 MB. It did not move.

The transfer really did run: between the first and second sample AnonPages rises 128 kB, KernelStack rises 16 kB — exactly two new kernel stacks, dd and nc — and PageTables rises 44 kB, and all three stay put for the remaining thirteen samples. A dd | nc that never exits is by definition pushing as fast as the socket will drain.

One thing that log cannot tell us, and that is our fault. The script we gave you for this test samples only /proc/meminfo. Your camera has eth0 up as well as wlan0, so nothing in the capture proves which interface carried the traffic. The script with /proc/net/dev in it was the second one in our last message, and this was the first. If you still have the setup, one line answers it:

grep -E 'wlan0|eth0' /proc/net/dev

before and after a two-minute repeat, and the byte counters say which one moved.

There is a hint in your data already. The unaccounted figure steps up by 368 kB at the exact moment the transfer starts, and then never moves again for six minutes. The wired driver allocates its descriptor ring once at probe and would not step when traffic begins; a USB Wi-Fi driver that allocates per transfer would step, and would then sit at whatever high-water mark the load demands. That is suggestive of Wi-Fi, and of a bounded demand — but it is a hint, not a measurement.

Why your GK7205V300 does not clear the adapter

This is the part worth reading carefully, because you offered it as evidence for the adapter and it is not.

Those two cameras are not running comparable memory configurations. From the device profiles in OpenIPC/builder, general/overlay/usr/share/openipc/customizer.sh:

	gk7205v300 ivg-g6s-w	gk7205v210 ivg-g4f-a-w
`totalmem`	`128M`	not set
`osmem`	`64M`	not set
allocator	`set_allocator cma`	not set

That is not an oversight in your board's profile — it is the designed default. load_goke chooses the allocator from totalmem, which defaults to 64:

if [ ${mem_total} -ge 128 ]; then set_allocator cma; else set_allocator gk; fi

so a 64 MB Goke board is meant to run the vendor allocator with mem=${osmem:=32M} and no CMA region. Your own boot log agrees on every point:

Kernel command line: mem=32M ... mmz_allocator=gk
Memory: 27140K/32768K available (... 0K cma-reserved)
cma zone is not set!

So one camera gives Linux 27 MB with no CMA pool, and the other gives it 128 MB with a 64 MB CMA pool — roughly four times the memory, plus a proper accounted region for driver DMA instead of the fallback path.

And the Wi-Fi driver is the same module on both. In general/overlay/etc/wireless/usb in OpenIPC/firmware, both entries end in the same modprobe atbm603x_wifi_usb with no parameters; the only difference in the GK7205V300 entry is a devmem/set_gpio pair that powers the adapter on that board. Same driver, same options.

So "it works perfectly on the other camera" tells us the adapter's memory demand is comfortably absorbed by 128 MB. It does not tell us the demand is small, and it does not clear the driver.

Where that leaves us

board	RAM Linux can see	CMA	adapter	result
your GK7205V210	27 MB	no	ATBM6012B	climbs
our bench camera	35 MB	no	Realtek	flat
your GK7205V300	~128 MB	yes	ATBM6012B	fine

The driver differs between rows 1 and 2. The memory differs between rows 1 and 3. Nothing so far separates the two explanations, and we are not going to guess between them.

Note that our bench camera has no CMA either, and did not climb. So "no CMA zone" on its own does not cause this. But it has 35 MB against your 27 — 30% more, not four times — so it is a weaker control than we would like.

The one test that separates them

Change how your GK7205V210 splits its 64 MB, and change nothing else:

fw_printenv bootargs        # write this down first, so you can restore it exactly
fw_setenv osmem 40M
set_allocator gk
reboot

This stays inside the designed configuration — same vendor allocator, same everything, only the split moves — and it is the configuration our bench camera already runs on the same SoC family, so it is not novel. After the reboot, cat /proc/cmdline should say mem=40M and MemTotal should read about 35 MB.

Then repeat the RTMP test and watch the same figure.

If it still climbs at roughly 27 kB/s and merely takes longer to hurt, the memory size is only changing how fast you notice, and the allocation is the driver's.
If it stops climbing, the allocation is driven by memory pressure, and the answer is the split, not the driver.

Either result is progress, and it is reversible with fw_setenv osmem 32M && set_allocator gk && reboot.

Three cautions, please read them before you type anything.

This edits the boot arguments. If the camera does not come back you will need a serial console to recover it. If you do not have one, skip this test and use the sampler below instead — we would rather have no data than a bricked camera.
It takes 8 MB away from the video memory pool. Your log shows the pipeline using 19.5 MB of the 32 MB available (Free MMZ mem before allocation: 32476KB down to Free MMZ mem finally: 12968KB), so 24 MB should still fit — but check Free MMZ mem finally in the log after the change and make sure it is still comfortably positive.
Do not combine this with enabling the second stream. We suggested enabling it as a workaround last time; that also costs video memory. Do one or the other, not both at once.

If you would rather not touch the boot arguments

Then the sampler from our last message is the thing to run, because it summarises /proc/vmallocinfo by caller. If the growth goes through vmalloc, that output names the module responsible outright, and no configuration changes are needed to get it.

One thing that is now fixed

The silent substream substitution — the camera publishing the main stream when the second stream is disabled, no matter what the outgoing setting says — is fixed. The camera now warns about it in its log, and the settings page shows the warning under the option itself, so nobody else has to discover it the way you did. It will be in the nightly builds. Thank you for finding it.

The memory question stays open.

Here is the exact verification you requested with eth0 completely disabled (ifconfig eth0 down):

Before transfer:
wlan0: RX 400959 B, TX 9139868 B
eth0: RX 0 B, TX 0 B
MemAvailable: 16 MB

After ~2 minutes of streaming:
wlan0: RX 1730525 B, TX 51630293 B (+42.5 MB strictly over wlan0!)
eth0: RX 0 B, TX 0 B
MemAvailable: 11 MB

Memory steadily continues to decrease at the exact same ~27 kB/s rate until the camera crashes with OOM. The issue is strictly isolated to the ATBM6012B USB WiFi driver/TX path under load.

P.S. I decided to try the default build (not vixand) to check and found that in your new nightly build the save button on the "outgoing" tab has disappeared and there are errors in the console.

P.P.S I have tested a 100% clean, official gk7205v210_lite_generic build (no vendor overlays, pure OpenIPC generic). The result is strictly identical: the exact same ~27 kB/s unrecoverable memory leak occurs under outgoing WiFi load. The issue is purely inside the ATBM6012B USB driver / xHCI DMA buffer path.

Settings: the substitution warning reads the field's value before the…

Про ваш P.S. — кнопка сохранения на вкладке Outgoing. Воспроизвели, нашли причину, исправление уже в master.

Это не логика RTMP. Ошибка была в JavaScript самой страницы настроек, и её разбудило как раз то изменение в majestic, которое вы заметили. majestic начал присылать в схеме новую пометку x-requires — ею отмечен «RTMP substream», чтобы страница могла сказать вслух: пока второй поток выключен, публикуется главный. Именно этого не хватало в вашем случае — вы переключали настройку, ничего не менялось, и выглядело это так, будто настройка ни на что не влияет.

Блок, который рисует это предупреждение, обращался к значению поля раньше, чем оно объявлено в коде. В JavaScript это не «пусто», а ReferenceError — исключение вылетало наружу и обрывало отрисовку прямо на месте. Поэтому вкладка и показывала только три поля из семи, а панель сохранения строится после полей и не появлялась вовсе. В минифицированной сборке имя переменной сжато до одной буквы, отсюда и загадочное Cannot access 'S' before initialization в консоли.

Вкладка Record ломалась ровно так же и по той же причине — там та же пометка на «Record substream».

Раньше это не проявлялось потому, что блок срабатывает только на поле, у которого в схеме есть x-requires, а до вчерашнего изменения ни одна камера такой пометки не присылала.

Что вы увидите после обновления. Правка в majestic-webui#315, собранный архив уже обновлён, так что ближайшая ночная сборка её заберёт. На вкладке Outgoing вернутся все семь полей и кнопка сохранения, а под переключателем «RTMP substream» появится строка «The sub stream is disabled, so the main stream is published instead.» — она показывается только когда переключатель включён, а второй поток выключен, и исчезает, как только вы включите video1.

Спасибо, что сообщили отдельным сообщением и с консолью на скриншоте — по одному только «пропала кнопка» это искали бы гораздо дольше.

Утечка памяти — отдельный разговор, ваши последние два замера с выключенным eth0 и на чистой generic-сборке никуда не делись, отвечаем по ним в основной ветке.

In English, for the rest of the thread:

Your P.S. — the missing Save button on the Outgoing tab. Reproduced, diagnosed, and the fix is merged.

It was not the RTMP logic. The bug was in the settings page's JavaScript, and the majestic change you noticed is exactly what woke it. majestic began shipping a new x-requires annotation in its schema, applied to RTMP substream, so the page could finally say out loud that with the sub stream disabled the main stream is published instead — the very thing that was missing in your case, where toggling the setting changed nothing and read as the setting being irrelevant.

The block that draws that warning read the field's value before the line declaring it had run. In JavaScript that is a ReferenceError, not an empty value, so the exception escaped and aborted the render where it stood: three of seven fields, and no save bar at all, because the bar is built after the fields are. Minification compresses the variable name to a single letter, hence the opaque Cannot access 'S' before initialization.

The Record tab failed identically, on the same annotation applied to Record substream.

Nothing caught it earlier because the block only runs on a field whose schema carries x-requires, and until yesterday's change no camera emitted one.

What you will see after updating. The fix is majestic-webui#315; the distribution archive is already refreshed, so the next nightly picks it up. Outgoing gets all seven fields and its Save button back, and under the RTMP substream switch a line reading "The sub stream is disabled, so the main stream is published instead." — shown only when that switch is on and the sub stream is off, and gone the moment you enable video1.

Thank you for reporting it separately and with the console visible in the screenshot; from "the button is gone" alone this would have taken considerably longer to find.

The memory leak is a separate matter — your last two measurements, with eth0 down and on a clean generic build, stand, and we are answering those in the main thread.

First, a correction, because you built your last two messages on something I got wrong.

I told you the module "prints not CONFIG_USE_DMA_ADDR_BUFFER when it starts — it allocates transfer buffers per transfer rather than reusing a fixed pool." That is backwards. In hal_apollo/apollo_usb.c, atbm_usb_urb_malloc() does one atbm_kzalloc() per URB, once, at probe when that symbol is off, and reuses those buffers for the life of the module; the other branch is the one that takes a single large usb_alloc_coherent region. And CONFIG_USE_DMA_ADDR_BUFFER is only defined when CONFIG_USB_AGGR_URB_TX is, which your build does not set — so the coherent-DMA path is not compiled in at all. There is no per-transfer DMA buffer and no xHCI DMA buffer path to blame. I am sorry for sending you down that road.

Reading the driver properly, though, turned up something better.

Your RX buffers are 32 kB each, and your sampler cannot see them

There are two public drops of this driver, and you are running the newer one. Your boot log gives it away twice: AsmLite probe! and idProduct[888b] exist only in gtxaspec/atbm-wifi, which is what the atbm-wifi buildroot package builds and what produces the module name in your log, atbm6012b_wifi_usb. The older drop, openipc/atbm_60xx, builds atbm603x_wifi_usb.

In your drop, hal_apollo/bh_usb.h reads:

//#ifdef CONFIG_USB_AGGR_URB_TX
//#define RX_BUFFER_SIZE 12*1024
//#else
#define RX_BUFFER_SIZE 16*1024//(1024*4-100)
//#endif

The conditional is commented out, so it is 16 kB unconditionally. In the older drop the same line is #define RX_BUFFER_SIZE 4000.

That one number decides everything about how this looks in /proc/meminfo:

	your drop	older drop
`RX_BUFFER_SIZE`	16384	4000
`alloc_skb()` request	~16.8 kB	~4.4 kB
kernel serves it from	page allocator, order-3	`kmalloc-8192` slab cache
physical cost per buffer	32768 B	8192 B
counted in `Slab:`	no	yes

On a 32-bit kernel with 4 kB pages, kmalloc stops using slab caches above 8192 bytes and calls the page allocator directly. Those pages are counted in no field of /proc/meminfo — not Slab, not AnonPages, not Cached. They land in exactly the gap we have been watching grow.

And the arithmetic lands where it should: 27.2 kB/s is 0.83 of one 32 kB buffer per second.

That also explains the thing that has been bothering me for three days — why Slab sat flat at 5.3 MB while 6.7 MB went missing. If this were the older driver, a leak of RX buffers would have shown up in Slab immediately and we would have found it on day one.

What this does and does not prove

It does not prove there is a leak. A 16 kB RX buffer is legal; the driver allocates sixteen of them for its RX ring and recycles them. What it proves is that if anything in this driver mislays an RX buffer, it costs 32 kB and is invisible to every measurement you have taken so far — and that the rate we measured is a hair under one buffer per second.

There is also a second failure mode that fits your numbers just as well and is not a leak at all. Order-3 allocations are the first thing to fail when memory fragments, and your camera has 27 MB and no CMA zone to absorb them. A driver that allocates and frees 32 kB blocks at a few hundred per second on a box that size will shred the buddy allocator, and the symptom of that is also "free memory disappears and never comes back, then OOM".

/proc/buddyinfo separates the two, and costs nothing:

while :; do date; grep -E 'MemTotal|MemFree|Buffers|^Cached|AnonPages|Slab|PageTables|KernelStack' /proc/meminfo; cat /proc/buddyinfo; echo; sleep 30; done > /tmp/buddy.log

Run it across a climb. If the order-3/4/5 columns collapse toward zero while the low orders stay populated, it is fragmentation. If everything drains evenly, something is holding the buffers.

The one-line thing worth trying

Since the older drop of the same driver uses 4000 here, the cheapest experiment is to make yours match:

/* hal_apollo/bh_usb.h */
#define RX_BUFFER_SIZE 4000

That is what atbm603x_wifi_usb has shipped with for years on the same chip family. It takes the RX ring from 512 kB to 128 kB, moves every RX buffer back into a slab cache where your sampler can see it, and removes the order-3 allocations entirely. If the climb stops, or drops by roughly 8x, we know what we are dealing with. If it carries on at 27 kB/s with Slab now rising instead of the gap, that is even better — it means we can watch it in slabtop.

Before that, two questions, because they may make the experiment unnecessary:

What does fw_printenv wlandev say, and what is in ls /lib/modules/*/extra/ | grep atbm? Both wireless entries for your board in OpenIPC/firmware general/overlay/etc/wireless/usb end in modprobe atbm603x_wifi_usb, yet your log loads atbm6012b_wifi_usb. If both modules are on the image, swapping to the other one is a rmmod/modprobe away and needs no build at all.
Which module does the GK7205V300 load? If it is atbm603x_wifi_usb while the V210 loads atbm6012b_wifi_usb, then the two cameras differ in the driver as well as in the memory split, and my previous message — which told you the driver was identical on both — was wrong about that too.

The definitive test, if you are willing to build

The driver ships its own leak detector, and the distribution build compiles it out. hal_apollo/Makefile has:

ccflags-$(MEM_DEBUG) += -DATBM_ALLOC_MEM_DEBUG
ccflags-$(SKB_DEBUG) += -DATBM_ALLOC_SKB_DEBUG

Turn both on — in the buildroot package, ATBM_WIFI_MODULE_MAKE_OPTS += SKB_DEBUG=y MEM_DEBUG=y — and the module keeps a list of every live allocation and every live skb, each tagged with the function that made it, published at:

/sys/module/atbm6012b_wifi_usb/atbm_mem/atbmmem
/sys/module/atbm6012b_wifi_usb/atbm_skb/atbmskb

The first line of each is the one that matters and is never truncated: mem_lis:add[N],del[M],left[K] and n_drows[..],n_inserts[..]. Sample them either side of a climb. If left, or n_inserts - n_drows, grows with your traffic, the driver is leaking and the call[...] entries name the function that allocated what is stuck. If both hold steady while the gap grows 27 kB/s, the driver is cleared by its own instrumentation rather than by anyone's argument, and we look elsewhere with a clear conscience. It also covers frames handed down by the network stack, because the bundled mac80211/tx.c registers every transmitted skb with the same tracker.

If building this is awkward, say so and we will prepare the module — we will need to know your exact firmware version so it matches your kernel.

Two driver bugs found on the way

Neither explains your leak; recording them because they are real and someone should fix them upstream.

atbm_usb_xmit_data_complete() has three early returns — hw_priv == NULL, !init_done, and bh_error — that skip atbm_usb_urb_put(). Each one permanently burns one of only 32 TX URB slots and strands the frame attached to it. bh_error is set by atbm_bh_halt() from the RX sequence check, so on a marginal link this is reachable, and the symptom would be TX slowing and then stopping, not memory growth.

atbm_tx_h_skb_pad() calls skb_padto(), which frees the skb itself when it fails; the caller then falls through to drop: and passes the same pointer to atbm_skb_dtor(). On USB this is currently unreachable, because atbm_usb_align_size() returns its argument unchanged, but it is live on the SDIO variant of this driver.

For completeness: I also checked whether the newer drop fixed a leak that the older one has. It did not — the differences are runtime chip-version checks replacing compile-time ones, a BLE bridge, and a changed RX length-mismatch path. The RX_BUFFER_SIZE change above is the one that matters, and it went the wrong way.

Update with definitive test results:

We compiled the module with your exact recommendations: #define RX_BUFFER_SIZE 4000, SKB_DEBUG=y, and MEM_DEBUG=y.
Build time verified: 2026-09-04_13-45-59.

Driver internal instrumentation:
/sys/module/atbm6012b_wifi_usb/atbm_mem/atbmmem:
Baseline: add[3308], del[3216], left[92]
After 2 min streaming: add[59554], del[59462], left[92]
Zero leak in driver kmalloc/kzalloc (56,246 allocs, exactly 56,246 frees, left stayed rock-steady at 92).
/sys/module/atbm6012b_wifi_usb/atbm_skb/atbmskb:
n_drows[76137], n_inserts[76154] -> exactly 17 skbs in flight out of 76,154 frames.
/proc/net/sockstat: TCP: mem 116 (only 464 kB).
Yet the memory was being drained:
During Outgoing RTMP streaming, MemFree dropped to 1032 kB, and orders 3..8 in buddyinfo collapsed completely to zeros:
Node 0, zone Normal 44 70 22 0 0 0 0 0 0 0 0
Stopping the stream (outgoing.enabled false) did not recover the memory.
The smoking gun (rmmod atbm6012b_wifi_usb):
The instant we executed rmmod atbm6012b_wifi_usb, 12.5 MB of RAM immediately flooded back into the system:
MemFree instantly jumped from 1,032 kB to 13,540 kB (available 18 MB).
buddyinfo immediately restored all higher orders:
Node 0, zone Normal 76 87 10 70 36 26 11 4 1 0 0 (70 order-3, 36 order-4, 26 order-5, 11 order-6, 4 order-7, 1 order-8).
Conclusion:
The driver's internal allocations (kmalloc, skb) are clean, but the USB transfer layer / xhci-hcd TRB rings / DMA mapping for this USB Wi-Fi interface holds onto ~12-15 MB of kernel pages under continuous TX streaming, and only releases them on usb_deregister(). On a 64MB SoC (with only ~27MB free for Linux), this ring expansion suffocates the buddy allocator and triggers OOM.

Yes, it is still open, and you are owed a straight answer rather than another round of tests. Six days of silence on our side was too long — sorry.

Where it actually stands

Your last run killed the theory I had put my name to. I wrote that xHCI transfer-ring expansion was the mechanism that fitted every observation, and attached the measurement that would confirm it. The measurement came back negative: no dma_pool_alloc anywhere in /proc/vmallocinfo, nothing near the megabytes, no Ring expansion failed in the log, and cutting the in-flight URBs to four changed nothing. That was too strong a word for something I had not yet tested, and it was wrong.

txqueuelen 16 came back negative too, so frames backing up above the driver are out as well.

Between your testing and ours, this is now ruled out:

ruled out	by what
majestic's own memory	heap flat across every run, reproduced on our bench
the ATBM driver's `kmalloc`/`kzalloc`	your `atbmmem`: 56,246 allocations, 56,246 frees, `left[92]` unchanged
the driver's skbs	your `atbmskb`: 17 live out of 76,154
socket and TCP memory	your `sockstat`: 116 pages
RX buffer size	you set it to 4000; no change
frames queued above the driver	you set `txqueuelen 16`; no change
URB depth	you built with 4/4; no change
xHCI ring expansion	your `vmallocinfo`; no `dma_pool_alloc` at all
the board being small	we rebuilt your exact memory configuration — `mem=32M`, `MemTotal 27336 kB`, no CMA — and pushed 7.1 GB through a USB adapter with `MemFree` held between 1.4 and 1.8 MB. Nothing moved.

What is left is about 12.5 MB of scattered pages that are not slab, not vmalloc, not socket memory, and are released the moment the device is torn down. Nothing in /proc names the owner of a raw page allocation, which is why we have run out of things to ask you to read.

The honest limit

We do not have an ATBM6012B, or any AltoBeam adapter, in the lab. Every reproduction we have run used a Realtek dongle on the same SoC family, the same kernel, the same xHCI controller and — after we mirrored it — the same memory configuration as yours. The one variable we cannot control is the one that differs, and it is the adapter. That is why our bench keeps coming back flat while yours does not, and it is not something more testing on our side will fix.

The one thing that would end this

CONFIG_PAGE_OWNER. It records the allocation stack of every page in the system, so instead of us inferring the owner from what is not growing, the kernel prints it.

Your kernel already has CONFIG_STACKTRACE=y, so three options and a boot parameter are all it needs:

CONFIG_PAGE_EXTENSION=y
CONFIG_PAGE_OWNER=y
CONFIG_DEBUG_FS=y

fw_setenv extras page_owner=on      # OpenIPC appends ${extras} to bootargs

Then reproduce the climb and take one dump:

cat /sys/kernel/debug/page_owner > /tmp/po.txt

Sorted by allocation site, that names what is holding the 12.5 MB, in one shot. If it points at the ATBM driver we will take it to AltoBeam with your measurements; if it points somewhere in the USB or network stack it becomes a kernel matter for the firmware project.

You do not have to build this yourself. gk7205v210_lite is a supported target in the firmware tree, so we can build the image with those options enabled and hand it to you — we just cannot run it here. Say the word and it is yours; you have done far more of this work than any reporter should have to, and building a kernel is the least we can do.

What happens to this issue

It stays open, and it is now labelled no hardware — the same label we use for anything we cannot reproduce because the lab does not own the part. That is not a polite way of closing it. It means the issue is parked in a state where anyone who has a GK7205V210 with an AltoBeam adapter, ourselves included if one reaches us, can pick it up with every measurement in this thread already done. If someone reading this has that combination spare and wants to donate it, that is the fastest way to get it off the shelf.

You are the exception, of course: you do have the hardware. Which is why the page_owner dump above is still by far the quickest route to an answer, and why the offer to build you the image stands.

On upgrading your hardware

Straight answer, since you asked it straight.

Your GK7205V300 works, and we have no reason to think it will stop. If you need this camera streaming reliably now, that is the honest recommendation, and you should not wait on us. The configuration at issue is specifically this one: a GK7205V210 giving Linux 27 MB with no CMA zone, publishing over that particular adapter. Nothing we have found suggests majestic or the WebUI is the problem, so a firmware update is not going to fix it either.

I am not going to give you a date. We do not have the hardware, we have run out of hypotheses we can test without it, and inventing a schedule for a fix we cannot reproduce would not be honest. What I can promise is that if the page_owner dump names the culprit, it gets fixed or escalated to whoever owns the code, and this thread gets the answer either way.

Thank you for the extraordinary amount of testing you have done here — the instrumented driver build in particular. Very few reports get taken this far by the person filing them.

I built and flashed the kernel with CONFIG_PAGE_OWNER=y, CONFIG_PAGE_EXTENSION=y, CONFIG_DEBUG_FS=y on my GK7205V210 board, booted with page_owner=on, reproduced the memory exhaustion under an active RTSP stream, and captured /sys/kernel/debug/page_owner.
Here is the allocation breakdown from the dump (accounting for ~24.5 MB of the 27.3 MB total RAM):

Summary by Call Site

Memory	Pages	Allocations	Key Call Chain
4.5 MB	1130	1130 (order 0)	`pagecache_get_page` <- `squashfs_copy_cache`
3.0 MB	762	762 (order 0)	`__vmalloc_node_range` <- `module_alloc` (vendor + atbm modules)
2.6 MB	640	80 (order 3)	`__alloc_page_frag` <- `__netdev_alloc_skb` <- `atbm_process_ieee80211_frame`
5.4 MB	1352	1038 (mixed)	`new_slab` <- `___slab_alloc`
2.7 MB	680	680 (order 0)	`handle_mm_fault` (Majestic heap/stack)
1.8 MB	457	457 (order 0)	`shmem_getpage_gfp` (tmpfs `/tmp`)
0.7 MB	174	87 (order 1)	`copy_process`

Key finding: ATBM RX path holding `order 3` (32 KB) compound pages

There is no single 12.5 MB rogue leak. Rather, with Linux receiving only 27.3 MB total (MemTotal: 27336 kB), the system has very little headroom.
The critical memory pressure point appears in the ATBM RX path:

Page allocated via order 3, mask 0x2095220(GFP_ATOMIC|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC)
PFN 264528 type Unmovable Block 258 type Movable Flags 0x4000(head)
 save_stack+0x48/0xf8
 __set_page_owner+0x30/0x5c
 get_page_from_freelist+0x288/0x778
 __alloc_pages_nodemask+0x144/0x9cc
 __alloc_page_frag+0x3c/0x164
 __netdev_alloc_skb+0x84/0xfc
 atbm_process_ieee80211_frame+0x128/0x1ec [atbm6012b_wifi_usb]
 atbm_rx_tasklet+0x144/0x268 [atbm6012b_wifi_usb]
 tasklet_action+0x74/0xa4
 __do_softirq+0x19c/0x214
In hal_apollo/bh_usb.c: Both atbm_process_ieee80211_frame and atbm_rx_multi_rx call atbm_get_skb(wsm_len + 16) -> atbm_dev_alloc_skb() -> __netdev_alloc_skb(). In this kernel, __netdev_alloc_skb() routes to netdev_alloc_cache via __alloc_page_frag(). Because PAGE_FRAG_CACHE_MAX_SIZE is 32768, it allocates order-3 compound pages (32 KB contiguous) marked as Unmovable.

The dump shows 80 order-3 blocks (77 of which are directly from ATBM). In a tight 27 MB pool, pinning ~2.5 MB in unmovable 32 KB blocks in atomic context quickly causes page allocation failures and OOM under stream traffic. When ifconfig wlan0 down is executed, these skb fragments are released, explaining why the memory returned on teardown.

Important context: Stock Xiongmai (iCSee / XMEye) firmware works reliably
It is worth noting that on the stock Xiongmai firmware (running the standard Sofia / iCSee / XMEye stack on this exact same camera board and ATBM6012B adapter), there are no memory exhaustion or crash issues — 24/7 streaming works completely stable.

This strongly indicates that the underlying hardware is fully capable of running stable on this board, and points to a kernel / driver memory allocation difference between the stock XM environment and OpenIPC (such as how SKB allocations or page_frag orders are handled, or socket buffer constraints).

You found it. That page_owner dump is the answer, and it is a good one.

I checked every step of your reasoning against the 4.9.37 source and it holds:

/* net/core/skbuff.c, __netdev_alloc_skb() */
len += NET_SKB_PAD;
if ((len > SKB_WITH_OVERHEAD(PAGE_SIZE)) ||
    (gfp_mask & (__GFP_DIRECT_RECLAIM | GFP_DMA))) {
        skb = __alloc_skb(len, gfp_mask, SKB_ALLOC_RX, NUMA_NO_NODE);
        ...
}
...
data = __alloc_page_frag(nc, len, gfp_mask);

SKB_WITH_OVERHEAD(PAGE_SIZE) is 3776 on this kernel and PAGE_FRAG_CACHE_MAX_SIZE is 32768, so a ~1.6 kB frame falls between the two thresholds, takes the netdev_alloc_cache path, and is carved out of an order-3 compound page — exactly the stack you captured. One surviving frame keeps all 32 kB pinned, they are Unmovable because they come from the RX tasklet under GFP_ATOMIC, and in a 27 MB kernel they end up scattered through Movable pageblocks the buddy allocator can then never coalesce. Hence the drain, the collapsed high orders, the memory not returning when the stream stops, and all of it coming back at teardown.

It also explains why we could never reproduce it. Our bench adapter is a Realtek, and its driver does not copy every received frame through netdev_alloc_skb at that size. We pushed 7.1 GB through an identical board and saw nothing, because the code path simply is not there.

Your Xiongmai observation fits too: the same silicon with a different driver build behaves, which is what you would expect when the fault is one allocation call and not the hardware.

Candidate fix

It is one function, atbm_get_skb() in hal_apollo/bh_usb.c, whose only two callers are the RX copy paths you found. alloc_skb() takes the kmalloc route instead of the page-frag cache: slab pages are reused for the same size class rather than accumulating, a single surviving frame cannot hold 32 kB hostage, and the memory becomes visible in Slab where it can be accounted for. NET_SKB_PAD is reserved by hand because that is the headroom __netdev_alloc_skb() would have left.

It applies cleanly to the current gtxaspec/atbm-wifi tree and compiles without errors in both USB_USE_TASTLET_TXRX branches, cross-built against a 4.9.37 tree with the OpenIPC toolchain.

--- a/hal_apollo/bh_usb.c
+++ b/hal_apollo/bh_usb.c
@@ -298,12 +298,33 @@
 	return (id==WSM_RECEIVE_INDICATION_ID)||(id == WSM_SMARTCONFIG_INDICATION_ID);
 }
 //#define ALLOC_SKB_NULL_TEST
+/*
+ * RX copies must not come from the per-cpu netdev page-frag cache.
+ *
+ * dev_alloc_skb()/__netdev_alloc_skb() serves any request below
+ * SKB_WITH_OVERHEAD(PAGE_SIZE) out of netdev_alloc_cache, and that cache is
+ * refilled with PAGE_FRAG_CACHE_MAX_ORDER (order-3, 32 KiB) compound pages.
+ * A received frame is ~1.6 KiB, so every RX copy lands inside one of those
+ * and the whole 32 KiB block stays pinned until the last frame carved out of
+ * it is freed.  Allocated GFP_ATOMIC from the RX tasklet they are Unmovable,
+ * and on a camera whose kernel owns ~27 MiB they end up scattered through
+ * Movable pageblocks that the buddy allocator can then never coalesce back
+ * into high orders.  The symptom is memory that drains under streaming load,
+ * does not return when the stream stops, and reappears all at once when the
+ * interface is torn down.
+ *
+ * alloc_skb() takes the kmalloc path instead: ~2 KiB out of a slab cache, no
+ * compound page held hostage by one surviving frame, and accounted in
+ * /proc/meminfo Slab where it can be seen.  Reserve NET_SKB_PAD by hand,
+ * since that is the headroom __netdev_alloc_skb() would have left.
+ */
 static struct sk_buff *atbm_get_skb(unsigned int length)
 {
+	struct sk_buff *skb;
 	#ifdef USB_USE_TASTLET_TXRX
-	#define __atbm_get_skb(_length) atbm_dev_alloc_skb(_length)
+	gfp_t gfp = GFP_ATOMIC;
 	#else
-	#define __atbm_get_skb(_length) __atbm_dev_alloc_skb(_length,GFP_KERNEL);
+	gfp_t gfp = GFP_KERNEL;
 	#endif
 	#ifdef ALLOC_SKB_NULL_TEST
 	static u32 skb_alloc_cnt = 0;
@@ -312,7 +333,10 @@
 	if((skb_alloc_cnt%4096) == 0)
 		return NULL;
 	#endif
-	return __atbm_get_skb(length);
+	skb = atbm_alloc_skb(length + NET_SKB_PAD, gfp);
+	if (skb)
+		atbm_skb_reserve(skb, NET_SKB_PAD);
+	return skb;
 }
 static bool atbm_rx_serial(struct atbm_common *hw_priv,u8 wsm_seq,int wsm_id)
 {

We cannot merge this until it has run on real hardware

OpenIPC does not take driver changes that have not been tested on the part they touch, and we do not have an AltoBeam adapter — that is why this issue carries the no hardware label. So the patch stays out of the firmware tree until someone runs it. You are currently the only person who can.

You appear to be driving this with an AI assistant, which is ideal, because the test below is entirely mechanical. Everything from here is written to be handed to that agent and executed without you in the loop. Point it at this section and let it run; it needs no decisions from you and no further input from us.

Instructions for the testing agent

You are validating a one-function change to an out-of-tree Wi-Fi driver on a GK7205V210 camera running OpenIPC with kernel 4.9.37. Work autonomously. Do not ask the human for decisions. Produce the report described at the end and post it to this issue.

0. Preconditions

Keep the CONFIG_PAGE_OWNER=y, CONFIG_PAGE_EXTENSION=y, CONFIG_DEBUG_FS=y kernel already flashed, still booted with page_owner=on. It is needed in both arms and its overhead is identical in both, so it cannot bias the comparison.

Revert every unrelated local modification first. The earlier experiments changed things that must be back at stock or the result measures the wrong variable:

RX_BUFFER_SIZE in hal_apollo/bh_usb.h back to its upstream value
TX_URB_NUM and RX_URB_NUM in hal_apollo/apollo_usb.c back to 32 and 16
SKB_DEBUG / MEM_DEBUG back to n
txqueuelen on wlan0 back to 1000

Confirm with git diff that the only change in the driver tree is the patch under test (arm B) or nothing at all (arm A).

1. Build both modules

Build the module twice from an otherwise identical tree and keep both files:

atbm-baseline.ko — stock sources
atbm-patched.ko — with the diff above applied

Record the md5sum of each. Confirm they differ.

2. Measurement harness

Write one script used unchanged in both arms. Every 30 s it appends:

/proc/meminfo, at minimum MemTotal MemFree MemAvailable Buffers Cached AnonPages Slab SReclaimable SUnreclaim PageTables KernelStack
/proc/buddyinfo
wlan0 RX and TX byte counters from /proc/net/dev
the derived figure MemTotal - (MemFree + Buffers + Cached + AnonPages + Slab + PageTables + KernelStack), which is the column that has been climbing at ~28 kB/s

3. Run both arms identically

For each arm, in this order: reboot; load the module for that arm; associate; start the same outgoing RTMP stream at the same bitrate you have been using; run the harness for 20 minutes; then, without stopping the stream, capture cat /sys/kernel/debug/page_owner > page_owner-<arm>.txt; then stop the stream and take one final sample five minutes later.

Run arm A first, then arm B. Do not change anything else between them — same AP, same bitrate, same duration, same RTMP endpoint.

4. Pass criteria

The patch passes only if all four hold. Report each one separately with its numbers.

The drain stops. The derived unaccounted figure in arm B is flat within ±512 kB across the 20 minutes, against roughly +33 MB/20 min implied by the ~28 kB/s previously measured. A reduced but still monotonic climb is a fail, not a partial pass — say so plainly.
The allocation site is gone. In page_owner-B.txt there are no order 3 allocations whose stack contains __alloc_page_frag beneath atbm_process_ieee80211_frame or atbm_rx_multi_rx. Grep for it explicitly and report the count in both arms.
The memory reappears where it should. Slab in arm B grows by roughly what the RX path now holds and then plateaus, rather than the unaccounted column growing. A plateau matters more than the absolute number.
The link still works. Over the 20 minutes, arm B's wlan0 TX byte rate is within 10% of arm A's, and dmesg shows no new driver errors, no wsm failures, no firmware reloads and no Ring expansion failed.

5. If it fails

Do not iterate on the patch. Collect and report: both page_owner dumps, both harness logs, dmesg from both arms, and git diff of the tree under test. A clean negative is as useful to us as a pass and we would rather have it quickly.

6. Report

Post one comment on this issue containing: the two md5sum values, the four pass criteria each answered yes or no with the numbers behind it, the before-and-after value of the unaccounted column at 0 and 20 minutes for both arms, the order 3 / __alloc_page_frag counts from both dumps, and the wlan0 TX totals. Raw numbers, not a summary. If anything in the protocol could not be carried out, say which step and why rather than substituting something else.

If this comes back green, we open the pull request against the firmware tree with your measurements attached and credit the diagnosis to you — the page_owner run is what solved it. If it comes back red, we have learned something real and this issue keeps its label until an adapter reaches someone who can take it further.

Moving this to the firmware tracker, because that is where the fix has to land.

Your page_owner dump settled it: the memory is consumed by order 3 page-fragment allocations under the ATBM USB Wi-Fi driver's receive path (__alloc_page_frag beneath the driver's frame-handling), and it is never returned while the interface stays up. That is a kernel driver issue, not a majestic one — majestic's own memory and the driver's own slab allocations were both ruled out earlier by your measurements. Nothing in the streamer can fix a leak that lives in the Wi-Fi driver's RX buffers.

The A/B patch test we agreed on still stands and is the way forward — this thread moves with it, so please post the results there. If the patched arm holds memory flat, we open the driver fix with your numbers attached and the diagnosis credited to you.

This was closed by mistake earlier today during a bulk triage and has been reopened. It stays tracked here. Sorry for the noise.

@prekrasnayaelena

@prekrasnayaelena, a reminder about the A/B run: the stock atbm_get_skb() against the alloc_skb() patch, 20 minutes each, with a page_owner dump from each. Nobody else has this board with an ATBM6012B adapter, so this issue can't move until that run is done.

A partial result helps too. If you could run only one side, or only a shorter run, post what you have and say which steps you skipped. If you can't run it any more, please say that as well. The issue then stays open under no hardware until someone with the adapter can take it over.

Merge pull request #1 from OpenIPC/make44-and-rx-alloc

Merge pull request #8 from OpenIPC/rx-copies-kmalloc

@prekrasnayaelena

@prekrasnayaelena we found the root cause and reproduced it without your hardware. The fix has landed. The short version is first; the details follow.

Root cause

Two things together, neither enough on its own:

Data the streamer received and never read. Before master+88fb005 (2026-10-05), majestic's outgoing RTMP connection didn't read what the server sent back: acknowledgements, pings and other small control messages. Each one stayed queued on the socket for the life of the connection. The server sends them in proportion to the data it receives, which is why the drain followed your bitrate and stopped when you covered the lens. Your builds were from early September.
The AltoBeam driver makes every queued reply cost 32 KiB. It copied each received frame with dev_alloc_skb(), which carves the frame out of a shared 32 KiB block. A block is freed only when every frame carved from it is freed, so one unread 100-byte reply keeps its whole 32 KiB alive. The socket is charged only the frame's own few hundred bytes, so the kernel's TCP memory limits never engage, and no field of /proc/meminfo shows the pinned blocks. Your ~27 kB/s is just under one pinned block per second. The pinned blocks also fragment memory: that's your empty buddy orders, and finally the OOM.

This explains everything you saw:

Ethernet was fine: the wired driver doesn't carve 32 KiB blocks, so unread replies cost little.
rmmod gave the memory back: the connection broke and its queue was freed.
Your page_owner dump: order-3 page-frag blocks under atbm_process_ieee80211_frame.
TCP: mem 116 in your log: the size of that unread queue.

Reproduction, no camera needed

We added a USB host to qemu-bench's gk7205v200 and gk7201v200 machines and used its emulated ATBM6012B (007a:888b), with your configuration: the gk7205v210 kernel, the atbm6012b_wifi_usb drop, mem=32M and Wi-Fi only. The load was an upload whose application never reads the 16-byte replies its server sends every 64 KiB.

	driver as you ran it	fixed driver
OOM	within 30 s	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
32 KiB blocks pinned by the driver	yes	0

When the application reads its replies, neither build drains. That's why our earlier bench runs never reproduced it: they all used a client that reads everything.

The fix

Driver: received frames are now copied with alloc_skb(), so a queued frame costs what it's charged and the socket limits hold. This is in Build under GNU make 4.4 on 4.9 kernels; RX copies from kmalloc (OpenIPC/firmware#2455) atbm-wifi#1 (OpenIPC's fork of gtxaspec/atbm-wifi, which the atbm-wifi package now fetches, pinned) and bh_usb: RX copies from kmalloc, so a queued frame cannot pin 32 KiB (OpenIPC/firmware#2455) atbm_60xx#8 (the atbm60xx and atbm603x-comb-openipc packages), and it's picked up by atbm: RX copies from kmalloc, so unread replies cannot pin 32 KiB each #2790.
majestic: master+88fb005 and later read and discard the server's messages.

Either one stops this drain on its own. The driver fix also protects against any other program that leaves received data unread.

What would confirm it on your camera

Update to a nightly built after 2026-11-08: sysupgrade -k -r. That one has both fixes. If you build your own image, the profile for your board selects atbm60xx, which is fixed too.
Stream the same RTMP output over Wi-Fi for 20 minutes and watch the memory.
Please tell us which module your camera actually loads: lsmod | grep atbm. Your boot log showed atbm6012b_wifi_usb, while the builder profile builds atbm603x_wifi_usb.

If memory stays flat, this is solved. If it doesn't, the same page_owner capture you did before will show us what's left.

atbm606x: RX copies from kmalloc, so a queued frame cannot pin 32 KiB

goke: gk7205v200 USB host, the same DWC3 as gk7201v200

atbm-wifi: a real link (HT/Block Ack, losses, paced uplink); gk7205v2…

A memory leak was detected when activating the Outgoing RTMP stream. gk7205v210_lite_vixand-ivg-g4f-a-w #2455

Description

Activity

openipc-ai commented on Sep 2, 2026

What we tried on the bench

The measurement that would settle it

One half of it we did reproduce

prekrasnayaelena commented on Sep 2, 2026

Managed by majestic. Comments and formatting are removed when settings change

via the web UI or API.

openipc-ai commented on Sep 2, 2026

One thing to fix in your config regardless

The measurement that would name the consumer

On the other half of the report

prekrasnayaelena commented on Sep 2, 2026

openipc-ai commented on Sep 3, 2026

What your log settles

What we did on our bench

What that leaves

Our own bug, which is real and separate

prekrasnayaelena commented on Sep 3, 2026

openipc-ai commented on Sep 3, 2026

Your test came back flat

Why your GK7205V300 does not clear the adapter

Where that leaves us

The one test that separates them

If you would rather not touch the boot arguments

One thing that is now fixed

prekrasnayaelena commented on Sep 3, 2026

prekrasnayaelena commented on Sep 3, 2026

prekrasnayaelena commented on Sep 3, 2026

openipc-ai commented on Sep 4, 2026

openipc-ai commented on Sep 4, 2026

Your RX buffers are 32 kB each, and your sampler cannot see them

What this does and does not prove

The one-line thing worth trying

The definitive test, if you are willing to build

Two driver bugs found on the way

prekrasnayaelena commented on Sep 4, 2026

12 remaining items

openipc-ai commented on Sep 10, 2026

Where it actually stands

The honest limit

The one thing that would end this

What happens to this issue

On upgrading your hardware

prekrasnayaelena commented on Sep 10, 2026

Summary by Call Site

Key finding: ATBM RX path holding order 3 (32 KB) compound pages

openipc-ai commented on Sep 11, 2026

Candidate fix

We cannot merge this until it has run on real hardware

Instructions for the testing agent

0. Preconditions

1. Build both modules

2. Measurement harness

3. Run both arms identically

4. Pass criteria

5. If it fails

6. Report

openipc-ai commented on Sep 19, 2026

widgetii commented on Oct 4, 2026

openipc-ai commented on Oct 26, 2026

widgetii commented on Nov 7, 2026

Root cause

Reproduction, no camera needed

The fix

What would confirm it on your camera

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Key finding: ATBM RX path holding `order 3` (32 KB) compound pages