Notifications
Clear all
Functionality Issues
2
Posts
2
Users
0
Reactions
323
Views
Topic starter
Subject: Kernel Panic on Tahoe 26.2 with ThunderBlade X12 - DarkWake Spinlock Timeout - Two Crashes
Hardware:
- MacBook Pro M4 Max 16" (clamshell mode, 3 external monitors)
- macOS 26.2 (Build 25C56)
- OWC ThunderBlade X12 (Model: OWCTB5TBL12X000)
- SoftRAID 8.6.1 / Driver 8.6
Issue: Two kernel panics occurring overnight while in clamshell mode. Both are spinlock timeouts triggered by mediaanalysisd during what appears to be DarkWake events. The Mac does not go into full sleep (settings prevent this), but DarkWake background tasks are running overnight.
Panic 1: com.apple.driver.SoftRAID 6.0 loaded (Apple's legacy driver) Panic 2: com.apple.driver.SoftRAID 8.6 loaded (OWC's current driver)
Both have identical signatures:
panic(cpu 3): Ticket spinlock timeout after ~3000000 ticks
Panicked task: mediaanalysisd
Performance cores offline (sleep state)
Configuration:
- "Prevent automatic sleeping on power adapter" = ON
- "Put hard disks to sleep" = Never
- "Wake for network access" = Only on Power Adapter
- SoftRAID volume excluded from Spotlight indexing (added after first crash, second crash still occurred)
Panic 2 timestamps confirm sleep/wake cycle:
Boot : 0x695c7bb4
Sleep : 0x695c7bd2
Wake : 0x695d1b05
Calendar: 0x695d2856 (panic)
Questions:
- Is there a known issue with SoftRAID 8.6 and DarkWake on Tahoe 26.2?
- Why did the first panic show Apple's legacy driver (6.0) instead of OWC's driver (8.6)?
- Is there a recommended workaround beyond disabling all wake events?
SoftRAID tech support file and both panic logs attached.
Immediate workaround: Set "Wake for network access" to Never to eliminate DarkWake events while OWC investigates. This should stop the overnight crashes.
Posted : 06/01/2026 12:19 pm
1. There is no known issue with Dark Wake and Tahoe, outside of Apples typical energy saving settings
2. the 6.0 SoftRAID did not and could not load. You are mistaken there.
3. Do not shut the lid when your drive is active. (ir disconnect the enclosure.
Does setting “Wake for network access” = Never eliminate DarkWake?
No — not completely.
It can reduce some DarkWake causes, but it does not eliminate DarkWake, especially on modern macOS with Thunderbolt storage and NVMe RAID.
Why DarkWake is still happening (even with those settings)
On macOS 13+ (and especially 14–15+), DarkWake is no longer just about networking.
DarkWake can be triggered by:
Thunderbolt bus power management
External storage power-state transitions
NVMe controller power-state changes
FileVault / APFS housekeeping
Time Machine / snapshot maintenance
System maintenance tasks (even with lid closed)
So even with:
Prevent sleep on power adapter = ON
Put disks to sleep = Never
Wake for network access = Never
…the system can still enter DarkWake-like low-power states when the lid is closed.
On laptops, lid closed always changes the power model.
Disabling “Wake for network access” may reduce some background wake events, but it does not prevent all DarkWake activity. On modern macOS, lid-closed operation can still trigger power-state transitions for Thunderbolt and NVMe devices. With large external NVMe RAID volumes, these transitions can expose firmware or bridge issues that lead to kernel panics. For stability testing, we recommend running with the lid open and system sleep disabled while the RAID is attached.
the bug is in the power management transition state. (SoftRAID is not in the backtrace, either)
Please do this test:
lid open
sleep disabled
same workload
If it stabilizes, you have a clear pointer to the problem.
Even if you unmount your volume, wait a bit, then close the lid, its likely to still encounter this, as MacOS will wake the drives every 45 minutes or so. that can trigger the same issues.
We have this in a list of reported issues for Apple.
Posted : 07/01/2026 5:58 pm
