TerraMaster Forum

Based on our analysis, this could be related to a bug in the kernel itself. However, the possibility of a hardware defect in the memory cannot be completely ruled out either. Please wait for further updates from us.

TMroy wrote: ↑20 Jun 2026, 15:38 Based on our analysis, this could be related to a bug in the kernel itself. However, the possibility of a hardware defect in the memory cannot be completely ruled out either. Please wait for further updates from us.

Thank you for the update and for confirming this is being investigated as a possible kernel-side issue.

I appreciate the engineering team taking this seriously, and I will continue to wait for further updates. I'm hopeful for a durable fix in the near future.

In the meantime, please don't hesitate to reach out if any additional data or testing on my side would help speed things up. The logs from all three incidents (13, 15 and 17 June) remain packaged and ready to send.

Thanks again for your continued work on this.

TMroy wrote: ↑20 Jun 2026, 15:38 Based on our analysis, this could be related to a bug in the kernel itself. However, the possibility of a hardware defect in the memory cannot be completely ruled out either. Please wait for further updates from us.

Another silent freeze on my unit — June 21 at 22:01, same signature as before: instant death, no kernel trace, no HDMI output, hard reset required. Logs submitted to support.
Still waiting for a resolution from the engineering team. At this point I would really appreciate any interim guidance, particularly on whether disabling the iSCSI/SCST service is safe and recommended while the investigation is ongoing.
Could this be a similar case to what exqo is experiencing — the same scst(OE) out-of-tree modules loaded, same VMA/memory-management corruption pattern across both TOS 6 and TOS 7?

exqo wrote: ↑21 Jun 2026, 02:48

Please send packaged debug logs to support email again for further analysis

rgrg1 wrote: ↑22 Jun 2026, 13:05

Please also send your new debug log to our support email, our engineering team will check it for you again.

MikeZhang wrote: ↑22 Jun 2026, 15:03

exqo wrote: ↑21 Jun 2026, 02:48

Please send packaged debug logs to support email again for further analysis

Done — debug logs for the 17 June event have just been sent to the support email (containing the full kernlog, syslog and freeze-watch snapshots). My unit has been stable since that reboot, now at ~5 days uptime.

Looking forward to any update from the engineering team.

MikeZhang wrote: ↑22 Jun 2026, 15:05

rgrg1 wrote: ↑22 Jun 2026, 13:05

Please also send your new debug log to our support email, our engineering team will check it for you again.

Today morning have been sent the logs already. Thank you in advance for your feedback.

exqo wrote: ↑22 Jun 2026, 16:34

Regarding the frequent crash issue you reported on your TNAS device, our technical team has analyzed the situation and recommends that you first perform the following two diagnostic checks:

1. Run a memory stability test to rule out hardware faults.
2. Reset the swap configuration (recreate the swap file).

These steps will help determine whether the crashes are caused by an abnormal swap partition or unstable memory modules.

1. Memory Test (MemTest86)
As the crash may be related to memory hardware stability, we suggest using MemTest86 to perform a full memory test.

Please follow these steps:

Create a MemTest86 bootable USB drive.
Boot the NAS from this USB drive.
Run a complete memory test – we recommend at least 4 full passes.
Watch for any errors (red error messages or "Error" indications).

If any memory errors appear during the test, please take a photo/screenshot and send it to us for further analysis.

2. Reset the Swap File
Please log in to your NAS via SSH and execute the following commands in sequence:

mkdir -p /Volume1/swap
chattr +C /Volume1/swap
dd if=/dev/zero of=/Volume1/swap/swapfile bs=1M count=4096 status=progress
chmod 600 /Volume1/swap/swapfile
mkswap /Volume1/swap/swapfile
swapon /Volume1/swap/swapfile
After running these commands, verify that the swap file is active by checking:

cat /proc/swaps
Make sure the output shows the correct file (/Volume1/swap/swapfile).

Once you have completed these operations, please enable debug mode on your NAS and continue using it as normal. Observe whether the crash issue reappears.

If the problem persists, please contact us again with any relevant logs or error messages, and we will continue to assist you in further diagnosing the issue.

MikeZhang wrote: ↑23 Jun 2026, 21:45

exqo wrote: ↑22 Jun 2026, 16:34

Thank you for the detailed response. I will proceed with the MemTest86 test as requested —I will share the outcome.

However, I would like to ask for clarification on the swap procedure before proceeding with that part.

Looking at my freeze-watch logs captured every 30 seconds across all three crash events, swap metrics were consistently clean throughout:

- SwapTotal: 1,997,820 kB
- SwapFree: 1,997,820 kB (100% free at every capture, including immediately before each crash)

Swap was never under pressure during any of the incidents. The kernel oops signatures (lookup_swap_cgroup_id page fault during runc exit, list_del corruption during qbittorrent-nox close() syscall) point to VMA / memory-management structures in the kernel, not to swap file activity.

Additionally, a previous response on this thread noted that "this could be related to a bug in the kernel itself" — which I understood as the engineering team's current working hypothesis.

Could you clarify how recreating the swap file addresses the observed kernel oops signatures, and whether this recommendation comes from the engineering team's analysis of my specific logs, or is a general diagnostic step? I want to make sure I'm running the right tests rather than introducing unnecessary changes to a configuration that currently appears stable.

Thanks again for your continued support.

exqo wrote: ↑24 Jun 2026, 01:46

Regarding our recommendation to recreate the swap file, we would like to clarify that this suggestion was not based on any confirmed evidence that the swap file itself is causing the issue. Rather, it was proposed as a diagnostic step during our initial investigation, with the goal of further narrowing down the scope of possible causes.

Based on the data you provided, Given the current crash information, we also cannot rule out the possibility of a kernel-level issue at this stage.

Therefore, recreating the swap file should be viewed as a troubleshooting measure rather than a fix for a confirmed root cause. We also greatly appreciate the detailed logs and analysis you have provided, as they are extremely helpful in our ongoing efforts to identify and isolate the underlying issue.