Kernel Panic on OpenWrt 25.12.4 (Linux 6.12.87) with Docker qBittorrent

Installing and Using OpenWrt
1

Kernel Panic on OpenWrt 25.12.4 (Linux 6.12.87) with Docker qBittorrent

Environment

Hardware:

Intel N100
NUC32R
BIOS 5.27 (2025-02-21)

System:

OpenWrt 25.12.4
r32933-4ccb782af7

Linux 6.12.87
x86_64

Docker installed.

qBittorrent runs inside Docker.

Docker network:

Bridge network
Subnet: 172.18.0.0/24
IPv6 enabled

Problem

The router randomly reboots under network load.

Persistent logging shows these reboots are kernel panics.

Three crashes have been recorded so far.

All crashes show:

Comm: qbittorrent-nox
Oops: general protection fault
Kernel panic - not syncing: Fatal exception

The crash occurs at exactly the same kernel RIP address every time.

Crash #1

Tue Jun 23 09:26:14

Comm: qbittorrent-nox
RIP: 0xffffffff818cd04c

Kernel panic - not syncing: Fatal exception

Crash #2

Tue Jun 23 14:33:32

Comm: qbittorrent-nox
RIP: 0xffffffff818cd04c

Kernel panic - not syncing: Fatal exception

Crash #3

Wed Jun 24 04:27:09

Comm: qbittorrent-nox
RIP: 0xffffffff818cd04c

Kernel panic - not syncing: Fatal exception

Observations

The panic signature is identical every time:

RIP: 0xffffffff818cd04c

The crashing process is always:

qbittorrent-nox

Only CPU number and PID differ.

This looks reproducible rather than random hardware corruption.

System Health Checks

Memory:

No OOM events observed.
Several GB of memory available at runtime.

Conntrack:

nf_conntrack_count = 1160
nf_conntrack_max   = 262144

Network statistics:

CRC errors = 0
RX/TX errors = 0
Timeouts = 0

Thermal status:

No thermal warnings observed.

Additional Notes

The same hardware previously ran another OpenWrt-based firmware for a long period without kernel panics.

The issue only appeared after moving to:

OpenWrt 25.12.4
Linux 6.12.87

The crash always involves:

qbittorrent-nox
Docker bridge networking
nftables stack

Has anyone seen similar crashes involving:

  • Linux 6.12.87
  • nftables
  • nft_tproxy / nft_socket
  • Docker bridge networking
  • qBittorrent

Any suggestions for identifying RIP 0xffffffff818cd04c or known fixes would be appreciated.

2

Network Hardware

NIC Driver:

igc

Interfaces:

eth0: Intel 2.5GbE (igc)

eth1: Intel 1GbE (igc)

No link errors observed:

CRC errors = 0

RX/TX errors = 0

timeouts = 0

3

Is eth0 your wan device?

I have seen crashes on N100 with igc with 2.5G enabled

If you don't need the 2.5Gbps, then set it to 1G:

ethtool -s eth0 autoneg on speed 1000 duplex full

you can place this command in webif under System->Startup->Local Startup

In case you need 2.5G, try this:

ethtool -A eth0 rx off tx off autoneg off

it fixed crashes for me with 2.5G.

4

Thanks for the suggestion!

I checked my setup:

  • eth1 is my WAN (1 Gbps)
  • eth0 is my LAN (2.5 Gbps)

So eth0 isn’t the WAN interface in my case, but it is still the 2.5G igc port that carries most of the LAN traffic.

Flow control on eth0 was enabled by default:

Autonegotiate: on
RX: on
TX: on

I’ve now disabled it with:

ethtool -A eth0 rx off tx off

I’ll leave the system running for a few days and report back whether the kernel panics disappear. If this fixes it, it could point to an igc driver issue rather than qBittorrent itself.

Thanks again for sharing your experience!

5

The only "LAN traffic" passing the LAN NIC is the one going to internet.
I assume you've got a switch in front of it ?

6

Thanks again!

You were right to point out that the WAN interface is actually eth1.

Initially I only disabled flow control on eth0, but after your comment I tested eth1 as well.

It turned out that I also had to disable pause autonegotiation:

ethtool -A eth1 autoneg off rx off tx off

Now ethtool -a eth1 reports:

Autonegotiate: off
RX: off
TX: off

I’ve now disabled pause frames on both igc interfaces and will run the system under the same workload for a few days.

I’ll report back with the results. Thanks for the suggestion!