[Bug Report] Severe Kernel Panics (Oops) when launching Chromium on Omni3576 - Memory/GPU driver issue (Debian 6.1.75)
Posted: 2026-03-23 3:08
Hardware: Luckfox Omni3576 (8GB RAM, 64GB Storage)
OS: Official Luckfox Debian 12 (bookworm)
Kernel: Linux luckfox 6.1.75 #4 SMP Fri Jan 30 10:30:35 CST 2026 aarch64
Description of the Issue:
I am experiencing critical system crashes (Kernel Panics) exclusively when attempting to use Chromium. The issue points directly to a bug in the Rockchip GPU/VPU drivers or the kernel's memory management (MMU) when handling memory allocation requests (mmap) from the browser or the compositor.
As I intend to use this board for computer vision and AI projects relying on OpenCV and the RKNN toolkit, having a stable kernel that can handle graphical and memory-intensive tasks without panicking is absolutely critical.
Below is the detailed evidence and the different scenarios tested:
Scenario 1: Launching Chromium normally (Native Desktop)
Opening Chromium directly from the desktop environment immediately freezes the entire board. SSH connections drop, and the system requires a hard reset.
Looking at the syslog and journalctl -k -b -1, the system throws a Kernel Panic related to a Level 2 translation fault:
Note: A secondary Oops was also logged for PID 2370 (Compositor) failing at do_madvise and __arm64_sys_madvise.
Scenario 2: Mitigation via Software Rendering
To isolate the GPU driver, I launched Chromium via SSH with hardware acceleration disabled:
chromium --disable-gpu --disable-software-rasterizer --disable-dev-shm-usage
Result: The browser opened and the immediate Kernel Panic was avoided. The terminal output showed expected driver failures:
libGL error: failed to load driver: rockchip
Warning: vkCreateInstance failed with VK_ERROR_INCOMPATIBLE_DRIVER
However, without the GPU/VPU, the CPU usage (chromium-bin --type=renderer) spiked to ~142%, pushing the Load Average to 7.64. Eventually, simply changing a YouTube video caused the system to freeze completely again.
Scenario 3: Fresh OS Reinstall & VNC Test
To rule out any corrupted packages, I completely reflashed the official Luckfox Debian image. I then connected via VNC and attempted to open Chromium.
Result: Immediate VNC disconnection and complete system lockup. The SSH terminal caught the following syslog broadcast before dying:
Troubleshooting steps already taken:
Could the engineering team please investigate the Rockchip display/GPU drivers and the memory allocation mapping in this specific 6.1.75 kernel build? The board's hardware is incredibly capable, but these kernel panics make desktop/multimedia usage impossible at the moment.
Any patches, updated kernel builds, or workarounds to stabilize the graphical environment would be highly appreciated. Thank you for your support.
OS: Official Luckfox Debian 12 (bookworm)
Kernel: Linux luckfox 6.1.75 #4 SMP Fri Jan 30 10:30:35 CST 2026 aarch64
Description of the Issue:
I am experiencing critical system crashes (Kernel Panics) exclusively when attempting to use Chromium. The issue points directly to a bug in the Rockchip GPU/VPU drivers or the kernel's memory management (MMU) when handling memory allocation requests (mmap) from the browser or the compositor.
As I intend to use this board for computer vision and AI projects relying on OpenCV and the RKNN toolkit, having a stable kernel that can handle graphical and memory-intensive tasks without panicking is absolutely critical.
Below is the detailed evidence and the different scenarios tested:
Scenario 1: Launching Chromium normally (Native Desktop)
Opening Chromium directly from the desktop environment immediately freezes the entire board. SSH connections drop, and the system requires a hard reset.
Looking at the syslog and journalctl -k -b -1, the system throws a Kernel Panic related to a Level 2 translation fault:
Code: Select all
Message from syslogd@luckfox ...
kernel:[ 449.395298] Internal error: Oops: 0000000086000006 [#1] SMP
kernel:[ 449.887719] Code: bad PC value
...
Unable to handle kernel paging request at virtual address ffffffc005675e0c
Mem abort info:
ESR = 0x0000000086000006
EC = 0x21: IABT (current EL), IL = 32 bits
FSC = 0x06: level 2 translation fault
...
CPU: 2 PID: 2338 Comm: chromium-bin Tainted: G O 6.1.75 #4
Call trace:
vm_unmapped_area+0x2a0/0x2d0
do_mmap+0xe0/0x484
__arm64_sys_mmap+0x34/0x44Scenario 2: Mitigation via Software Rendering
To isolate the GPU driver, I launched Chromium via SSH with hardware acceleration disabled:
chromium --disable-gpu --disable-software-rasterizer --disable-dev-shm-usage
Result: The browser opened and the immediate Kernel Panic was avoided. The terminal output showed expected driver failures:
libGL error: failed to load driver: rockchip
Warning: vkCreateInstance failed with VK_ERROR_INCOMPATIBLE_DRIVER
However, without the GPU/VPU, the CPU usage (chromium-bin --type=renderer) spiked to ~142%, pushing the Load Average to 7.64. Eventually, simply changing a YouTube video caused the system to freeze completely again.
Scenario 3: Fresh OS Reinstall & VNC Test
To rule out any corrupted packages, I completely reflashed the official Luckfox Debian image. I then connected via VNC and attempted to open Chromium.
Result: Immediate VNC disconnection and complete system lockup. The SSH terminal caught the following syslog broadcast before dying:
Code: Select all
Message from syslogd@luckfox at Mar 22 21:34:32 ...
kernel:[ 337.276321] Internal error: Oops: 000000009600004e [#1] SMP
Message from syslogd@luckfox at Mar 22 21:34:32 ...
kernel:[ 337.671910] Code: eb0000ff 54000069 b5fffee0 f94014c0 (a9010265)- Upgraded power supply to a high-quality, high-amperage unit. (Issue persists, ruling out power dips).
- Fresh OS flash. (Issue persists).
- Disabled GPU via flags. (Delays the crash, but CPU bottlenecks and freezes).
Could the engineering team please investigate the Rockchip display/GPU drivers and the memory allocation mapping in this specific 6.1.75 kernel build? The board's hardware is incredibly capable, but these kernel panics make desktop/multimedia usage impossible at the moment.
Any patches, updated kernel builds, or workarounds to stabilize the graphical environment would be highly appreciated. Thank you for your support.