Hi I need some help troubleshooting a kernel panic that started frequently happening for me starting somewhere around 7/10.

So far I think I've isolated the issue to the DelugeVPN docker as the system operates normally when the docker is shut down or no files are downloading. I've posted to the DelugeVPN support thread but my gut is telling me this could be a hardware failure so posting here as well might be helpful.

Immediately after starting the docker I am able to view the UI, downloads start downloading, and the memory usage for DelugeVPN shown in the docker tab starts climbing and climbing until eventual kernel panic 

Here's some info about my setup and some steps I've taken to troubleshoot

• I've ran memtest86 with 0 errors
• I've completely destroyed the container and rebuilt from scratch including re-downloading the opvn files from PIA
• Deluge writes to an unassigned disk for incomplete data and seed directory
• No hardware changes
• Have used this config for > 5 years with no hiccup or crash

This is the repeating error in the Deluged logs. By the time of the kernel panic this warning has repeated 1000s of times
10:59:23.491 [WARNING ][deluge.core.torrentmanager    :1639] on_alert_performance: <torrent_name>: performance warning: max outstanding piece requests reached, outstanding_request_limit_reached

 

Attached are pictures of the kernel panics, a diagnostic dump of the system during download - if left alone for another 5 min it would crash and I wouldn't have an opportunity to take diagnostic dump

tower-diagnostics-20210721-1433.zip

Here is the latest crash along with the syslog up to the point of the crash.

syslog

The docker crashed again, this time the UI was responsive so I tried to reboot the system. The shutdown procedure failed but in its failures it would generate a diagnostic dump which I've attached.

 

Any help getting to the root of this would be greatly appreciated

tower-diagnostics-20210722-1830.zip

This looks more like a hardware issue, though strange that it appears to be caused by a particular docker.

6 hours ago, JorgeB said:

This looks more like a hardware issue, though strange that it appears to be caused by a particular docker.

 

Exactly my thoughts, any clues to which hardware. I have enough spares to swap out everything but going one by one will be awful

I would start with board/CPU.