Re: [Help] F4-424 unreachable every 48-72h (or less)
Posted: 24 Jun 2026, 19:36
Hello,MikeZhang wrote: ↑23 Jun 2026, 21:45Regarding 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.
Following your previous recommendations, I have completed the MemTest86 diagnostic and would like to share the results along with an update on my system state.
MemTest86 Results — RAM is sound
MemTest86 V11.7 Free (Build 1000), 4 complete passes, all 48 sub-tests passed:
- Test Start Time: 2026-06-25 05:59:14
- Elapsed Time: 2h 22m 34s
- CPUs Active: 4
- CPU Temperature (Min/Max/Avg): 40°C / 69°C / 60°C
- RAM Temperature (Min/Max/Avg): 33°C / 52°C / 45°C
- **Tests Completed: 48/48 (100%)**
- **Tests Passed: 48/48 (100%)**
- **Total errors: 0**
- **ECC errors: 0**
- Bits in Error Mask: 0000000000000000
The Hammer Test (Test 13), which is the most stress-intensive memory test, completed without any error. RAM module: KingboMars Technology Co Ltd A-SRAMD5-8G-SC4800M, DDR5 4800MT/s.
This confirms what was already suggested by another F4-424 user in our forum thread (7 passes clean): **the RAM is not the cause of the kernel oops events**.
Notable observation during testing
I required three attempts to complete the full 4-pass test. The exact timing and conditions are documented in the attached MemTest86 log files:
- Attempt 1 (log MemTest86-20260624-200058): test started at 20:01:30, NAS rebooted spontaneously around 20:23:25 (after ~22 minutes), during the Hammer Test of Pass 1 (segment 0x0-0x100000000). Pass 1 never completed. 0 errors logged. CPU 56°C / RAM 40°C at the time of reboot.
- Attempt 2 (log MemTest86-20260624-202427): test started at 20:24:59, Pass 1 completed cleanly at 20:46:55 (~22 minutes, 0 errors), Pass 2 started immediately, NAS rebooted spontaneously around 21:25:41 (after ~1 hour of total testing), during the Hammer Test of Pass 2 (segment around 0x180000000-0x200000000). 0 errors logged in any pass. CPU 54°C / RAM 40°C at the time of reboot.
- Attempt 3 (final, log MemTest86-20260625-055843): test started at 05:59:15, all 4 passes completed successfully without reboot, finished at 08:21:48. Test result: PASS, 0 errors across all 48 sub-tests including all 4 Hammer Tests.
Both spontaneous reboots in attempts 1 and 2 occurred specifically during the Hammer Test phase (the most stress-intensive sub-test), but the third attempt completed the same Hammer Test phases 4 times without issue. The logs show no memory errors before the reboots — the system simply reset abruptly, cutting the log mid-test. I am unable to determine the cause with certainty, but mention it for transparency in case it's useful to your engineering team (possible thermal/power/firmware transient under sustained stress at cold start).
On the swap reset recommendation — not yet executed
I have **not yet executed** the second part of your recommendation (the swap file reset):
```
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
```
The reason for holding off: looking at my freeze-watch logs captured at 30-second intervals across all three crash events (13, 15, 17 June), 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 any 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 rather than to swap file activity.
Given that an earlier response on the forum indicated this might be a kernel-level issue, I would appreciate clarification before proceeding: **could you explain how recreating the swap file is expected to address 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.
I will of course execute it if you confirm it is the correct next step.
System update — TOS 7.0.0746 stable
I have updated my NAS to **TOS 7.0.0746 stable** (the official release, previously I was on TOS 7.0.0612 beta).
I noticed that the TOS update regenerated grub on the boot partition (now `grub.bz2` compressed format instead of plain `grub.cfg`), which overwrote my previously applied `intel_idle.max_cstate=1` kernel parameter that had been recommended for the C-state stability issue on N95.
C-state mitigation re-applied via sysfs fallback
As editing the new compressed grub.bz2 is risky and would be overwritten by every future TOS update, I have re-enabled the sysfs-based mitigation I had previously prepared as a fallback:
- Script: `/usr/local/bin/disable_deep_cstates.sh` (owner Adm1n:Adm1n, executable)
- Cron: `/etc/cron.d/cstate_fix` with `@reboot Adm1n /usr/local/bin/disable_deep_cstates.sh`
- Effect: disables cpuidle states 2, 3, 4 (C6/C8/C10) on all 4 cores via `/sys/devices/system/cpu/cpu*/cpuidle/state*/disable`
- Functionally equivalent to `intel_idle.max_cstate=1` (only POLL and C1E remain active)
- Verified working after reboot: cron triggered at boot, logger trace confirmed, all 4 cores show state2/3/4 disabled
- Advantage over the kernel parameter approach: survives TOS updates since it doesn't touch the bootloader
This is the configuration in which my NAS currently runs.
Updated state of the investigation
With the RAM ruled out by MemTest86 (both on my unit and on the other F4-424 user's unit), the hypothesis pointing to the out-of-tree TerraMaster modules (scst*, tmacl_vfs, blk_uevent) as the cause of the kernel oops events (lookup_swap_cgroup_id and list_del corruption) is now the strongest remaining one.
Could you please share an update from the engineering team on:
1. Whether the kernel oops investigation has progressed
2. Whether the out-of-tree modules are being looked at
3. Whether TOS 7.0.0746 stable includes any kernel/module changes that could affect this issue
I remain fully available for any additional testing your engineering team may need.
Thanks again for your continued work on this case.