[Help] F4-424 unreachable every 48-72h (or less)

[rgrg1]

Thank you for providing the screenshot.

Based on the information currently available, we can only confirm that the system experienced a Kernel Panic. However, since the screenshot only captures the crash screen itself and does not include the system logs before or after the event, we are unable to determine the root cause at this stage.

Could you please confirm whether Debug Mode had been enabled before the issue occurred?

If Debug Mode was enabled, please export the Debug log after the system has recovered and send it to our support email address. We will analyze the complete logs to review the system status leading up to the crash and determine whether the issue is related to software, drivers, hardware, or another underlying factor.

Thank you for your cooperation and support.

Thank you for the feedback. I have already sent the requested logs and information to the support email and am currently waiting for their response/solution.
They mentioned disabling SSD cache as a possible cause, but I replied that I don't have any SSD cache configured — no NVMe drives, no LVM cache pool, only SATA HDDs with linear LVM volumes.

Should I share here the logs?

[MikeZhang]

Don't need to share logs here, we will continue to follow up your case via email

[exqo]

Hello,

A new freeze event occurred on my unit on 13 June 2026 at ~21:15 (about 4 days of stable uptime after the previous incident). This time, with extended monitoring in place, I was able to capture a **complete kernel oops with full stack trace**. The data points clearly to a kernel-level bug, distinct from both the original C-state issue and the runc-cascade I previously reported.

I'm sharing the detailed diagnosis below in the hope it helps your kernel/firmware team investigate.

## Summary timeline

- 28 May: BIOS updated to BJFX-ADLN-109, intel_idle.max_cstate=1 applied → 12 days of stable operation
- 09 June ~16:00: first incident, runc cascade signature, no clear root cause identified at the time
- 09 June onwards: tnas-smartfan disabled, preventive CPU limits added on Prowlarr/Jellyseerr, Immich stopped to isolate variables → 4 days stable
- 13 June 21:15:59: kernel oops captured (details below)

## Kernel oops: page fault in lookup_swap_cgroup_id during runc exit

At 21:15:59 UTC+2 (kernel time t=349759.623245), the kernel oopsed on a runc process (PID 907562) that was in the process of exiting. The fault occurred deep in the cgroup memory swap controller while unmapping the dying process's address space.

**Sequence (extracted from kernlog_20260613):**

```
[349759.623252] Hardware name: retsamarret 000-F4424-FBA005-2000/M-ADLN01, BIOS BJFX-ADLN-109 11/15/2024
[349759.623255] RIP: 0010:lookup_swap_cgroup_id+0x2f/0x60
[349759.623290] CR2: ffffd6664067eff8
[349759.623294] Call Trace:
[349759.623299] <TASK>
[349759.623299] swap_pte_batch+0x92/0x220
[349759.623306] unmap_page_range+0xa63/0x1540
[349759.623317] unmap_vmas+0xb5/0x190
[349759.623321] exit_mmap+0xee/0x3a0
[349759.623325] __mmput+0x3e/0x130
[349759.623329] do_exit+0x2b7/0xac0
[349759.623338] do_group_exit+0x30/0x80
[349759.623341] get_signal+0x8c4/0x8f0
[349759.623346] arch_do_signal_or_restart+0x3e/0x250
[349759.623351] syscall_exit_to_user_mode+0x139/0x1b0
[349759.623356] do_syscall_64+0x8e/0x190
[349759.623413] entry_SYSCALL_64_after_hwframe+0x76/0x7e
```

The page fault address (CR2: ffffd6664067eff8) is in kernel space. The faulting instruction is in `lookup_swap_cgroup_id`, which is part of the cgroup v1 memory swap accounting. The path indicates a runc process was being terminated by a signal (futex syscall, ORIG_RAX=0xca) and the page fault occurred during teardown of its memory mappings (`unmap_page_range`).

**Aftermath:**

```
[349759.723166] note: runc[907562] exited with irqs disabled
[349759.723217] note: runc[907562] exited with preempt_count 1
[349759.723222] Fixing recursive fault but reboot is needed!
[349759.723224] BUG: scheduling while atomic: runc/907562/0x00000000
[349759.723524] Voluntary context switch within RCU read-side critical section!
[349759.723529] WARNING: CPU: 1 PID: 907562 at kernel/rcu/tree_plugin.h:331 rcu_note_context_switch+0x58e/0x610
```

The process died holding both interrupts disabled and an RCU read lock. The kernel itself states `reboot is needed`.

**Cascading effect (60 seconds later):**

```
[349819.724342] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
[349819.724351] rcu: Tasks blocked on level-0 rcu_node (CPUs 0-3): P907562/1:b..l
```

The orphaned RCU read lock blocks all subsequent `synchronize_rcu_expedited` calls system-wide. Over the next ~2 hours, this progressively blocks systemd, all md*_raid1 kernel threads, and any Docker operation that touches cgroups. By 21:55 the D-state count was 55 and the system was no longer responsive to SSH/TOS web (Beszel via Tailscale kept reporting metrics). A physical reboot was required.

## Loaded modules at the time of oops

Kernel was tainted `G O E` (out-of-tree, unsigned) before the fault. Out-of-tree TerraMaster modules loaded at the time include:

```
blk_uevent(OE) tmacl_vfs(OE) scst_raid(OE) scst_user(OE) scst_disk(OE)
scst_vdisk(OE) isert_scst(OE) iscsi_scst(OE) scst(OE)
```

I mention this only for completeness; I cannot determine whether any of these modules contributed to the fault.

## Current state

The unit is back up and stable since the 21:59 reboot. Configuration is unchanged from the post-09/06 state:

- BIOS BJFX-ADLN-109
- intel_idle.max_cstate=1 (verified active)
- tnas-smartfan disabled
- Immich stopped
- CPU limits on Prowlarr/Jellyseerr

I have not relaunched the full stack yet.

## Next steps on my side

Following your earlier suggestion, I now intend to switch the kernel parameter from `intel_idle.max_cstate=1` to `intel_idle.max_cstate=2`. The reasoning: the fault is clearly not a C-state issue per se, but POLL-only operation may increase the contention window for the cgroup memory race condition that caused the page fault. Allowing C1E should change kernel scheduling timing without re-exposing the original deep-idle wake-up bug. I'll report back on stability.

## Available logs for your team

I have the following files saved and can attach them on request, or share via a TOS Debug Log export:

- `/public/debug_log/kernlog_20260613` (159 KB) — full kernel ring buffer for 13 June, contains the complete oops + RCU stall sequence above
- `/public/debug_log/syslog_20260613` (1.1 MB) — full system log for 13 June
- `/system-logs/freeze-watch.CRASH-20260613-2007.log` — 30-second-interval snapshots covering ~2 hours before and during the freeze, with per-process CPU/RSS, per-container Docker stats, and dmesg tail

Let me know which format you prefer for the upload (TOS Debug Log archive, or individual files via support ticket).

Thank you for the continued investigation.

[rgrg1]

Hello,

A new freeze event occurred on my unit on 13 June 2026 at ~21:15 (about 4 days of stable uptime after the previous incident). This time, with extended monitoring in place, I was able to capture a **complete kernel oops with full stack trace**. The data points clearly to a kernel-level bug, distinct from both the original C-state issue and the runc-cascade I previously reported.

I'm sharing the detailed diagnosis below in the hope it helps your kernel/firmware team investigate.

## Summary timeline

- 28 May: BIOS updated to BJFX-ADLN-109, intel_idle.max_cstate=1 applied → 12 days of stable operation
- 09 June ~16:00: first incident, runc cascade signature, no clear root cause identified at the time
- 09 June onwards: tnas-smartfan disabled, preventive CPU limits added on Prowlarr/Jellyseerr, Immich stopped to isolate variables → 4 days stable
- 13 June 21:15:59: kernel oops captured (details below)

## Kernel oops: page fault in lookup_swap_cgroup_id during runc exit

At 21:15:59 UTC+2 (kernel time t=349759.623245), the kernel oopsed on a runc process (PID 907562) that was in the process of exiting. The fault occurred deep in the cgroup memory swap controller while unmapping the dying process's address space.

**Sequence (extracted from kernlog_20260613):**

```
[349759.623252] Hardware name: retsamarret 000-F4424-FBA005-2000/M-ADLN01, BIOS BJFX-ADLN-109 11/15/2024
[349759.623255] RIP: 0010:lookup_swap_cgroup_id+0x2f/0x60
[349759.623290] CR2: ffffd6664067eff8
[349759.623294] Call Trace:
[349759.623299] <TASK>
[349759.623299] swap_pte_batch+0x92/0x220
[349759.623306] unmap_page_range+0xa63/0x1540
[349759.623317] unmap_vmas+0xb5/0x190
[349759.623321] exit_mmap+0xee/0x3a0
[349759.623325] __mmput+0x3e/0x130
[349759.623329] do_exit+0x2b7/0xac0
[349759.623338] do_group_exit+0x30/0x80
[349759.623341] get_signal+0x8c4/0x8f0
[349759.623346] arch_do_signal_or_restart+0x3e/0x250
[349759.623351] syscall_exit_to_user_mode+0x139/0x1b0
[349759.623356] do_syscall_64+0x8e/0x190
[349759.623413] entry_SYSCALL_64_after_hwframe+0x76/0x7e
```

The page fault address (CR2: ffffd6664067eff8) is in kernel space. The faulting instruction is in `lookup_swap_cgroup_id`, which is part of the cgroup v1 memory swap accounting. The path indicates a runc process was being terminated by a signal (futex syscall, ORIG_RAX=0xca) and the page fault occurred during teardown of its memory mappings (`unmap_page_range`).

**Aftermath:**

```
[349759.723166] note: runc[907562] exited with irqs disabled
[349759.723217] note: runc[907562] exited with preempt_count 1
[349759.723222] Fixing recursive fault but reboot is needed!
[349759.723224] BUG: scheduling while atomic: runc/907562/0x00000000
[349759.723524] Voluntary context switch within RCU read-side critical section!
[349759.723529] WARNING: CPU: 1 PID: 907562 at kernel/rcu/tree_plugin.h:331 rcu_note_context_switch+0x58e/0x610
```

The process died holding both interrupts disabled and an RCU read lock. The kernel itself states `reboot is needed`.

**Cascading effect (60 seconds later):**

```
[349819.724342] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
[349819.724351] rcu: Tasks blocked on level-0 rcu_node (CPUs 0-3): P907562/1:b..l
```

The orphaned RCU read lock blocks all subsequent `synchronize_rcu_expedited` calls system-wide. Over the next ~2 hours, this progressively blocks systemd, all md*_raid1 kernel threads, and any Docker operation that touches cgroups. By 21:55 the D-state count was 55 and the system was no longer responsive to SSH/TOS web (Beszel via Tailscale kept reporting metrics). A physical reboot was required.

## Loaded modules at the time of oops

Kernel was tainted `G O E` (out-of-tree, unsigned) before the fault. Out-of-tree TerraMaster modules loaded at the time include:

```
blk_uevent(OE) tmacl_vfs(OE) scst_raid(OE) scst_user(OE) scst_disk(OE)
scst_vdisk(OE) isert_scst(OE) iscsi_scst(OE) scst(OE)
```

I mention this only for completeness; I cannot determine whether any of these modules contributed to the fault.

## Current state

The unit is back up and stable since the 21:59 reboot. Configuration is unchanged from the post-09/06 state:

- BIOS BJFX-ADLN-109
- intel_idle.max_cstate=1 (verified active)
- tnas-smartfan disabled
- Immich stopped
- CPU limits on Prowlarr/Jellyseerr

I have not relaunched the full stack yet.

## Next steps on my side

Following your earlier suggestion, I now intend to switch the kernel parameter from `intel_idle.max_cstate=1` to `intel_idle.max_cstate=2`. The reasoning: the fault is clearly not a C-state issue per se, but POLL-only operation may increase the contention window for the cgroup memory race condition that caused the page fault. Allowing C1E should change kernel scheduling timing without re-exposing the original deep-idle wake-up bug. I'll report back on stability.

## Available logs for your team

I have the following files saved and can attach them on request, or share via a TOS Debug Log export:

- `/public/debug_log/kernlog_20260613` (159 KB) — full kernel ring buffer for 13 June, contains the complete oops + RCU stall sequence above
- `/public/debug_log/syslog_20260613` (1.1 MB) — full system log for 13 June
- `/system-logs/freeze-watch.CRASH-20260613-2007.log` — 30-second-interval snapshots covering ~2 hours before and during the freeze, with per-process CPU/RSS, per-container Docker stats, and dmesg tail

Let me know which format you prefer for the upload (TOS Debug Log archive, or individual files via support ticket).

Thank you for the continued investigation.

Hello,

I had a very similar experience. After the BIOS update (BJFX-ADLN-109) and intel_idle.max_cstate=1, my unit also ran stable for about a week — then on June 11 at 08:17 it had a silent freeze with no HDMI output, identical signature to the original C-state issue. Hard reset required.

Later that day, during a normal shutdown attempt, the system hung again. After reboot, pstore contained a kernel Oops:
Oops: general protection fault, probably for non-canonical address
RIP: unlink_anon_vmas+0x23/0x1d0
Comm: redis-server, Tainted: G D OE, 6.12.63+ #14
Loaded out-of-tree modules at the time: scst, scst_disk, scst_vdisk, scst_raid, scst_user, iscsi_scst, isert_scst.

This is the same family of VMA/memory-management corruption I saw earlier this year on TOS 6 (move_to_new_folio, vma_interval_tree_remove, __rb_erase_color) — different kernel version (6.1.x vs 6.12.63), different triggering process, but the same subsystem and the same scst(OE) modules loaded both times.

I also ran MemTest86 (7 passes, all clean) — RAM is not the issue.

This looks like it could be the same cross-kernel-version VMA corruption pattern you're seeing with the runc/lookup_swap_cgroup_id oops — possibly originating from the scst out-of-tree modules tainting the kernel, rather than a pure upstream kernel bug.

[exqo]

Hello,

Thank you very much for sharing your analysis — the cross-kernel-version continuity you describe (TOS 6 kernel 6.1.x → TOS 7 kernel 6.12.63, same VMA / memory-management subsystem, same scst(OE) modules loaded both times) is a very important data point, and your clean MemTest86 result on a sibling F4-424 makes the case much stronger that this is not a RAM issue. Your scst(OE) hypothesis is plausible and worth investigating.

New event on my side: 15 June at 03:42

Less than 24 hours after the previous reboot, my unit froze again. My Docker stack at the time was the usual one (Beszel, Dockge, AdGuard, Jellyfin, Sonarr, Radarr, Prowlarr, Bazarr, Jellyseerr, qBittorrent + Gluetun + port-sync, FileBrowser, Tailscale, Rclone, Golink) — only Immich was kept stopped from the previous diagnostic round.

Kernel oops captured from /Volume1/public/debug_log:

```
[107054.017492] list_del corruption. prev->next should be ffff8c1df280e398, but was fffd8c1df280e398.
[107054.017512] kernel BUG at lib/list_debug.c:62!
[107054.017519] Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
[107054.017523] CPU: 3 PID: 128847 Comm: qbittorrent-nox Tainted: G OE 6.12.63+ #15
[107054.017534] RIP: 0010:__list_del_entry_valid_or_report+0xa7/0xc0

Call Trace:
__ep_remove+0x103/0x210
eventpoll_release_file+0x5b/0xb0
__fput+0x25f/0x2a0
__x64_sys_close+0x3c/0x80
do_syscall_64+0x82/0x190

[107065.190411] watchdog: Watchdog detected hard LOCKUP on cpu 1
[107114.120108] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks
```

Different function and process than the 13 June event (lookup_swap_cgroup_id / runc), but same picture: a process being torn down (here, a close() syscall releasing epoll resources) triggers corruption in a kernel data structure, leaving locks orphaned, followed by RCU stalls cascading across the system until a physical reboot is required.

The corruption is a single bit flip (f → d at one nibble position). The same out-of-tree TerraMaster modules were loaded as in the 13 June oops: scst, scst_raid, scst_user, scst_disk, scst_vdisk, isert_scst, iscsi_scst, tmacl_vfs, blk_uevent.

Summary of what we now know

- Two distinct F4-424 units with the same BIOS (BJFX-ADLN-109) and same kernel (6.12.63+) reporting the same family of memory-corruption oops
- At least one MemTest86 result clean (7 passes) → RAM is unlikely to be the cause
- The same scst(OE) and related TerraMaster modules loaded in every oops
- Pattern persists across two different mainline kernel versions (6.1.x and 6.12.63) → unlikely to be an upstream kernel bug
- Issue reproduces under varying Docker workloads

A note on how long this has been going on

I want to be direct with the support team: I have now been dealing with this issue for six months. My F4-424 crashes on average every 48 to 72 hours — sometimes faster, occasionally lasting a week or two before falling over again. Throughout that period I have:

- Run extensive diagnostics (atop, freeze-watch, monitor.sh, Beszel, Debug Mode logs)
- Applied every TerraMaster recommendation (BIOS update to BJFX-ADLN-109, intel_idle.max_cstate=1 kernel parameter)
- Tested numerous Docker stack configurations from full down to minimal
- Provided detailed kernel oops traces, syslog dumps, and per-process snapshots after every freeze
- Maintained patient, structured communication on this forum and via support tickets

At this stage I have a NAS that I cannot reliably use as a NAS. It is a six-month-old product that requires a physical power reset every two to three days, with data integrity risks at every cycle (so far BTRFS has held up, but that's not a guarantee that will continue). I have built up a substantial body of evidence pointing at the TerraMaster out-of-tree modules, and another F4-424 user is independently reporting the same symptoms.

I now need TerraMaster to engage substantively on this. If the issue cannot be diagnosed and fixed by the engineering team within a reasonable timeframe, I will have no choice but to request a unit replacement under warranty, and if a replacement reproduces the same software-side issue, to consider a refund on the grounds that the product does not deliver its core function reliably under EU consumer protection law.

I would much rather see a kernel/module fix — the hardware itself appears sound, the unit is well-built, and I would prefer to keep using it. But I need a concrete response and timeline from your engineering team.

Request to TerraMaster

Could the support team:

1. Confirm whether the out-of-tree modules (scst*, tmacl_vfs, blk_uevent) have any known issues with VMA / list management on TOS 7
2. Indicate whether the engineering team is actively investigating this class of oops on TOS 7 / kernel 6.12.63+
3. Provide an estimated timeframe for a kernel/module fix, even if rough

Full kernel oops traces, syslog and 30-second-interval pre-freeze snapshots from both my events are available immediately on request — already packaged and ready to send.

Thanks again for the continued collaboration. I remain available and willing to test anything your team needs me to test — but I would appreciate moving from data collection to actual resolution at this point.

Best regards

[MikeZhang]

If Debug Mode was enabled, please export the Debug log after the system has recovered and send it to our support email address. We will analyze the complete logs to review the system status leading up to the crash and determine whether the issue is related to software, drivers, hardware, or another underlying factor.

[exqo]

If Debug Mode was enabled, please export the Debug log after the system has recovered and send it to our support email address. We will analyze the complete logs to review the system status leading up to the crash and determine whether the issue is related to software, drivers, hardware, or another underlying factor.

Done !

[MikeZhang]

OK thanks, we have received your debug logs and have forwarded to our engineer team for analysis, as this is serious issue, it may take longer time to check and find solution carefully for you, please wait patiently, we will update once there is any result.

[exqo]

OK thanks, we have received your debug logs and have forwarded to our engineer team for analysis, as this is serious issue, it may take longer time to check and find solution carefully for you, please wait patiently, we will update once there is any result.

Thanks for the information


Quick update: a third freeze occurred this morning (17 June at 07:05), approximately 48 hours after the previous reboot. Same kernel oops signature as the 13 June event:

```
Jun 17 07:05:53 kernel: Oops: 0000 [#1] PREEMPT SMP NOPTI
Jun 17 07:05:53 kernel: RIP: 0010:lookup_swap_cgroup_id+0x2f/0x60
Jun 17 07:05:53 kernel: BUG: scheduling while atomic: runc/2464840/0x00000000
```

Same faulting function, same triggering process (runc), same outcome (RCU stall, hard reboot required). My unit is now averaging one crash every 24 to 96 hours and has been doing so for six months.

I now have three documented kernel oops events with full traces, plus a fourth user (myself) confirming the cross-kernel-version VMA / memory-management corruption pattern already discussed in this thread. Debug logs for the 17 June incident are packaged and ready to send if needed.

I understand the engineering team is analyzing this, but I would appreciate any indication of timeline or interim guidance. At this rate the unit is not usable in a reliable production capacity.

[MikeZhang]

Thanks for the update.

We are verifying a solution based on your logs, and we will update it here once we have confirmed it can help with the issue.