The system experiences a kernel panic after several hours of continuous streaming load. The watchdog correctly detects a hard lockup on one of the CPU cores and triggers a panic, but the system does not recover and requires a manual power cycle.

This issue was discovered while deploying the Raspberry Pi 5 as a dedicated camera node in a neuroscience research laboratory. The primary workload involves continuous, multi-day (24-48+ hours) video streaming to a central NVR server as auxiliary data for sleep studies in mice.

The kernel panic results in a hard system freeze, leading to a loss of video footage. Due to the synchronized nature of the experiments, any gap in the video recording compromises the integrity and usability of the primary scientific data collected during that period. The stability of the underlying TCP stack for long-duration streaming is therefore critical for this research application.

Steps to reproduce the behaviour

Install go2rtc on a Raspberry Pi 5 running the latest kernel

Configure two camera streams using rpicam-vid and expose them via RTSP

Have a client (in this case, Frigate) connect to and consume both streams continuously over RTSP/TCP

Within approximately 24-48 hours, a kernel panic related to memory management or the network stack occurs

Device (s)

Raspberry Pi 5

System

Hardware: Raspberry Pi 5 (8GB)

OS: Raspberry Pi OS (bookworm)

Kernel: Linux pi5-1 6.12.34+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.12.34-1+rpt1~bookworm (2025-06-26) aarch64 GNU/Linux

Network: Onboard Pi 5 ethernet

Workload: go2rtc streaming 2x RTSP cameras continuously over TCP for ~24-48h.

Logs

Aug 28 17:52:17.888577 pi5-1 kernel: Unable to handle kernel paging request at virtual address 0000000a7c400080
...
Aug 28 17:52:18.308990 pi5-1 kernel: Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP
...
Aug 28 17:52:18.332640 pi5-1 kernel: CPU: 1 UID: 1000 PID: 1955 Comm: node Not tainted 6.12.34+rpt-rpi-2712 #1 Debian 1:6.12.34-1+rpt1~bookworm
...
Aug 28 17:52:18.332856 pi5-1 kernel: Call trace:
Aug 28 17:52:18.332868 pi5-1 kernel: __kmalloc_node_noprof+0x1cc/0x3d0
Aug 28 17:52:18.332880 pi5-1 kernel: __kvmalloc_node_noprof+0x24/0x128
Aug 28 17:52:18.332893 pi5-1 kernel: io_uring_setup+0x2a8/0xdd8
Aug 28 17:52:18.332906 pi5-1 kernel: __arm64_sys_io_uring_setup+0x44/0x168
Aug 28 17:52:18.332919 pi5-1 kernel: invoke_syscall+0x50/0x120
Aug 28 17:52:18.332931 pi5-1 kernel: el0_svc_common.constprop.0+0x48/0xf0
Aug 28 17:52:18.332944 pi5-1 kernel: do_el0_svc+0x24/0x38
Aug 28 17:52:18.332956 pi5-1 kernel: el0_svc+0x30/0x100
Aug 28 17:52:18.332969 pi5-1 kernel: el0t_64_sync_handler+0x100/0x130
Aug 28 17:52:18.332981 pi5-1 kernel: el0t_64_sync+0x190/0x198

Aug 28 175037.262950 pi5-1 kernel p.txt

Additional context

No undervoltage or thermal throttling is detected (vcgencmd get_throttled = 0x0)

The power supply is the official Raspberry Pi usb-c

The SD card appears healthy with no I/O errors in dmesg

The issue is reliably reproducible

The crash appears to be related to the kernel's TCP stack under heavy, long-duration load. A potential workaround is to switch the RTSP transport protocol from TCP to UDP. This avoids the stateful connection management of TCP where the lockup seems to be occurring. This can be configured in the client application (Frigate)