RV1106 AOV: photo capture fails after ~50 sleep/wake cycles (mpp_vcodec errno 14 Bad address) + wake→capture latency >20
Posted: 2026-04-27 9:56
We are developing a battery‑powered wildlife camera based on RV1106 running Linux 5.10 with RKADK (Rockchip media framework). The device uses AOV (Always‑On‑Video) sleep/wake – it suspends to RAM (mem) and wakes on PIR or RTC.
Two issues:
1.Capture failure after many sleep/wake cycles
After about 50 successful cycles, the photo capture starts timing out (-2). The log shows:
mpp[386]: mpp_vcodec: ioctl fd 51 failed ret -1 errno 14 Bad address
mpp[386]: mpp: VCODEC_CHAN_CREATE channel 2 failed
[RKADK_E] RKADK_PHOTO_Init[1101]: RK_MPI_VENC_StartRecvFrame failed[a004800c]
After that, the pipeline cannot reinit, and subsequent captures fail immediately (-1). Rebooting the whole system fixes it temporarily.
2.Wake → capture latency exceeds 200ms
In AOV mode, we need capture to complete within 200 ms from wake. Our current timing is around 270–280 ms (see log snippet below). We have already pre‑switched IR‑CUT and ISP resume in the wake path, but still not fast enough.
Environment & Software
SoC: Rockchip RV1106 (luckfox pico pi A W rv1106g3)
Kernel: 5.10 (Rockchip BSP)
Userspace: RKADK (v0.0.0-local, built Apr 27 2026)
Application: Custom C code using RKADK_PHOTO_Init / RKADK_PHOTO_TakePhoto
Sleep mode: AOV (rkadk_aov) with SAMPLE_ISP_SingleFrame before sleep and MultiFrame after wake
Observed Logs
[RKADK_I] RKADK_PHOTO_TakePhoto[1378]: Photo[0] Take photo number = 1
ANALYZER:E:sof disorder, latest:3519, new:3519
...
[RKADK_E] capture_once_take_burst[474]: Capture failed at index 0, ret=-2
[WARN] Photo pipeline timeout — reinitializing to clear stuck state
...
mpp[386]: mpp_vcodec: ioctl fd 51 failed ret -1 errno 14 Bad address
mpp[386]: mpp: VCODEC_CHAN_CREATE channel 2 failed
[RKADK_E] RKADK_PHOTO_Init[1101]: RK_MPI_VENC_StartRecvFrame failed[a004800c]
Wake → capture timing
[2026-04-27 14:11:36] [INFO] === TIMING: wake→capture = 278 ms (task_start→capture = 134 ms) ===
We need this to be under 200 ms.
What we have tried
1. Process restart on consecutive failures – we have execv() on g_consec_capture_fail >= 2, but that path is not triggered reliably (the counter increments but restart never happens).
2. Hardware reset – calling RKADK_PHOTO_DeInit + RKADK_PHOTO_Init after a timeout. It fails with the same MPP error.
3. For ISP resume: we call SAMPLE_ISP_MultiFrame(0) immediately after wake, then wait 40–80 ms (depending on day/night). IR‑CUT is switched in parallel. Still not fast enough.
4. Reducing warm‑up – removing delays causes -2 timeouts even on early cycles.
Questions for the forum
1. Is the mpp_vcodec errno 14 a known kernel driver leak in RV1106 AOV use?
Has anyone found a workaround (e.g., unbinding/rebinding the VENC driver, or a hidden ioctl to reset the hardware block)?
2. How can we force a full kernel VENC reset without rebooting?
We already re‑init the userspace pipeline, but the driver remains stuck. Is there a sysfs trigger or a RK_MPI_VENC_ResetChn that actually resets the hardware?
3. What is the minimal ISP warm‑up time after SAMPLE_ISP_MultiFrame to guarantee first capture success?
We currently use 40 ms (day) / 80 ms (night). Is there a way to poll for “first ISP frame ready” instead of fixed sleep?
4. Any example code for sub‑200 ms wake→capture on RV1106 AOV?
We see 278 ms in our logs. The kernel rkisp and rkcif resume times seem to dominate. Are there DTS or kernel config tweaks to reduce resume latency?
5. Rockchip MPP maintainers: is there a planned fix for the errno 14 after multiple suspend/resume cycles?
If not, what is the recommended way to detect this “bad state” and force a full system reboot from userspace?
Two issues:
1.Capture failure after many sleep/wake cycles
After about 50 successful cycles, the photo capture starts timing out (-2). The log shows:
mpp[386]: mpp_vcodec: ioctl fd 51 failed ret -1 errno 14 Bad address
mpp[386]: mpp: VCODEC_CHAN_CREATE channel 2 failed
[RKADK_E] RKADK_PHOTO_Init[1101]: RK_MPI_VENC_StartRecvFrame failed[a004800c]
After that, the pipeline cannot reinit, and subsequent captures fail immediately (-1). Rebooting the whole system fixes it temporarily.
2.Wake → capture latency exceeds 200ms
In AOV mode, we need capture to complete within 200 ms from wake. Our current timing is around 270–280 ms (see log snippet below). We have already pre‑switched IR‑CUT and ISP resume in the wake path, but still not fast enough.
Environment & Software
SoC: Rockchip RV1106 (luckfox pico pi A W rv1106g3)
Kernel: 5.10 (Rockchip BSP)
Userspace: RKADK (v0.0.0-local, built Apr 27 2026)
Application: Custom C code using RKADK_PHOTO_Init / RKADK_PHOTO_TakePhoto
Sleep mode: AOV (rkadk_aov) with SAMPLE_ISP_SingleFrame before sleep and MultiFrame after wake
Observed Logs
[RKADK_I] RKADK_PHOTO_TakePhoto[1378]: Photo[0] Take photo number = 1
ANALYZER:E:sof disorder, latest:3519, new:3519
...
[RKADK_E] capture_once_take_burst[474]: Capture failed at index 0, ret=-2
[WARN] Photo pipeline timeout — reinitializing to clear stuck state
...
mpp[386]: mpp_vcodec: ioctl fd 51 failed ret -1 errno 14 Bad address
mpp[386]: mpp: VCODEC_CHAN_CREATE channel 2 failed
[RKADK_E] RKADK_PHOTO_Init[1101]: RK_MPI_VENC_StartRecvFrame failed[a004800c]
Wake → capture timing
[2026-04-27 14:11:36] [INFO] === TIMING: wake→capture = 278 ms (task_start→capture = 134 ms) ===
We need this to be under 200 ms.
What we have tried
1. Process restart on consecutive failures – we have execv() on g_consec_capture_fail >= 2, but that path is not triggered reliably (the counter increments but restart never happens).
2. Hardware reset – calling RKADK_PHOTO_DeInit + RKADK_PHOTO_Init after a timeout. It fails with the same MPP error.
3. For ISP resume: we call SAMPLE_ISP_MultiFrame(0) immediately after wake, then wait 40–80 ms (depending on day/night). IR‑CUT is switched in parallel. Still not fast enough.
4. Reducing warm‑up – removing delays causes -2 timeouts even on early cycles.
Questions for the forum
1. Is the mpp_vcodec errno 14 a known kernel driver leak in RV1106 AOV use?
Has anyone found a workaround (e.g., unbinding/rebinding the VENC driver, or a hidden ioctl to reset the hardware block)?
2. How can we force a full kernel VENC reset without rebooting?
We already re‑init the userspace pipeline, but the driver remains stuck. Is there a sysfs trigger or a RK_MPI_VENC_ResetChn that actually resets the hardware?
3. What is the minimal ISP warm‑up time after SAMPLE_ISP_MultiFrame to guarantee first capture success?
We currently use 40 ms (day) / 80 ms (night). Is there a way to poll for “first ISP frame ready” instead of fixed sleep?
4. Any example code for sub‑200 ms wake→capture on RV1106 AOV?
We see 278 ms in our logs. The kernel rkisp and rkcif resume times seem to dominate. Are there DTS or kernel config tweaks to reduce resume latency?
5. Rockchip MPP maintainers: is there a planned fix for the errno 14 after multiple suspend/resume cycles?
If not, what is the recommended way to detect this “bad state” and force a full system reboot from userspace?