Raspberry Pi 5 hard freeze under high NVMe I/O load (Frigate / InfluxDB) – system remains pingable but SSH and journald hang

[Boldfor]

Describe the bug

On a Raspberry Pi 5, the system occasionally enters a complete freeze under high NVMe I/O load.
The device remains reachable via ICMP (ping works), but:

• SSH becomes unresponsive
• systemd-journald stops processing logs
• no further kernel messages are emitted
• the system does not recover without a power cycle
• The issue occurs very rarely (weeks/months of stable uptime), but is reproducible by triggering heavy I/O, e.g.:
• scrubbing a long Frigate video timeline (NVMe read-heavy)
• querying a full year of data in openHAB backed by InfluxDB

This looks like an I/O or PCIe/NVMe stall rather than a userspace crash or OOM condition.

Steps to reproduce the behaviour

1. Raspberry Pi 5 running Raspberry Pi OS (64-bit), kernel 6.6.x+rpt-rpi-2712
2. System booted from NVMe (via Pineboards AI Bundle, M-Key)
3. Run Docker containers including:
   Frigate (video recordings on NVMe)
   InfluxDB
   openHAB
   RaspberryMatic / OpenCCU
4. Trigger high sustained NVMe load, e.g.:
   Scrub through a long Frigate video timeline
   Query a large time range (e.g. 1 year) in openHAB that hits InfluxDB
5. After some time (minutes), the system freezes:
   ping still works
   SSH and journald hang
   no recovery without power cycle

The issue does not happen under normal load and may require weeks to reoccur.

Device (s)

Raspberry Pi 5

System

Hardware:

• Raspberry Pi 5 Model B
• Pineboards AI Bundle (NVMe M-Key + E-Key, incl. Hailo 8L – not actively used)
• NVMe SSD (used as root filesystem and for Docker data)

Kernel:

• 6.6.74+rpt-rpi-2712 (Raspberry Pi kernel)

OS:

• Raspberry Pi OS 64-bit (Bookworm)

Storage:

• Root filesystem on NVMe

USB devices:

• Homematic RF stick (directly connected via USB extension cable)
• Zigbee + Z-Wave + Amber dongles (via active USB hub)

Issue also occurred previously with a passive hub

Containers (Docker):

• openHAB
• InfluxDB
• Frigate
• RaspberryMatic / OpenCCU

Logs

Relevant observations from logs before/during freezes:

• NVMe timeouts and aborts:

nvme nvme0: I/O timeout, aborting
I/O error, dev nvme0n1

• Journald overwhelmed or stalled:

/dev/kmsg buffer overrun, some messages lost
systemd-journald watchdog timeout

• No classic OOM signature before the freeze
• No soft-lockup watchdog messages
• After reboot, previous journal sometimes marked as uncleanly shut down

Full logs around the freeze are attached to this issue.

Additional context

The system can run perfectly stable for weeks or months

The freeze correlates strongly with high NVMe I/O pressure

USB power issues are unlikely:

• active USB hub in use
• freeze still occurs

Ping remaining functional suggests:

• kernel still partially alive
• likely blocked kernel threads (I/O / PCIe / NVMe path)

Similar behavior observed both with Frigate (video I/O) and InfluxDB (large queries)

If helpful, I can:

• test kernel parameters (e.g. NVMe power state limits)
• enable hung task panic for better diagnostics
• provide additional traces on next occurrence

[pelwell]

How is the system powered? Hard lockups under heavy load smell of undervoltage.

[Boldfor]

How is the system powered? Hard lockups under heavy load smell of undervoltage.

The system is powered via the original Raspberry Pi 5 27W power supply.

To rule out power issues on the USB side, I moved several radio dongles (Z-Wave, Zigbee, Amber) from a passive hub to an externally powered (active) USB hub. The Homematic RF stick is connected directly to the Pi via a short extension cable. This change did not alter the behavior; hard lockups still occurred under load.

Additionally, the crashes are reproducible without any USB radio activity by triggering high I/O and CPU load only (e.g. scrubbing Frigate video timelines or querying a full year of data from InfluxDB via openHAB). In these cases, no USB traffic is involved beyond standard peripherals.

What also speaks against a general undervoltage or insufficient power supply issue is the previously reported behavior in the OpenCCU issue tracker, where the same kernel-level symptoms (UART RX FIFO overruns, eq3loop buffer exhaustion, journald watchdog aborts) were observed under similar load conditions:
OpenCCU/OpenCCU#3407

So far, there are:

• no undervoltage or throttling warnings reported by the firmware,
• no HDMI or system instability outside of these high-load scenarios,
• long periods (weeks to months) of completely stable operation otherwise.

That said, if there are specific voltage or power telemetry points you would like me to capture (e.g. vcgencmd outputs under load), I’m happy to provide them.