exqo wrote: ↑14 Jun 2026, 14:18
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.