cjlmediasolutions

The issue is it rarely happens (or ever? I actually dont know if this is the first time Ive seen this specific issue). The system was up and running for 6 days before this even happened. I've had other issues and it's hard to tell if they are related or if its multiple issues at a time. Guess my point is taking them out could work but Id need to run the system without them for a long time to confirm which I cant really do atm lol.

Yeah, that's fair. I checked both NVMe drives (2x Kingston NV2 SNV2S1000G) and both are returning Read Self-test Log failed: Invalid Field in Command (0x002) when smartctl tries to read the self-test log. Everything else is clean - 0 errors, 100% spare, temps normal. Could this unsupported command response be the trigger for the kernel bug? smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.12.24-Unraid] (local build) Copyright (C) 2002-23, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Model Number: KINGSTON SNV2S1000G Serial Number: 50026B7686B7D65D Firmware Version: SBM02106 PCI Vendor/Subsystem ID: 0x2646 IEEE OUI Identifier: 0x0026b7 Controller ID: 1 NVMe Version: 1.4 Number of Namespaces: 1 Namespace 1 Size/Capacity: 1,000,204,886,016 [1.00 TB] Namespace 1 Formatted LBA Size: 512 Namespace 1 IEEE EUI-64: 0026b7 686b7d65d5 Local Time is: Wed Apr 29 16:23:07 2026 EDT Firmware Updates (0x12): 1 Slot, no Reset required Optional Admin Commands (0x0016): Format Frmw_DL Self_Test Optional NVM Commands (0x009f): Comp Wr_Unc DS_Mngmt Wr_Zero Sav/Sel_Feat Verify Log Page Attributes (0x12): Cmd_Eff_Lg Pers_Ev_Lg Maximum Data Transfer Size: 64 Pages Warning Comp. Temp. Threshold: 83 Celsius Critical Comp. Temp. Threshold: 90 Celsius Supported Power States St Op Max Active Idle RL RT WL WT Ent_Lat Ex_Lat 0 + 5.00W - - 0 0 0 0 0 0 1 + 3.50W - - 1 1 1 1 0 200 2 + 2.50W - - 2 2 2 2 0 1000 3 - 1.50W - - 3 3 3 3 5000 5000 4 - 1.50W - - 4 4 4 4 20000 70000 Supported LBA Sizes (NSID 0x1) Id Fmt Data Metadt Rel_Perf 0 + 512 0 0 === START OF SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED SMART/Health Information (NVMe Log 0x02) Critical Warning: 0x00 Temperature: 31 Celsius Available Spare: 100% Available Spare Threshold: 10% Percentage Used: 18% Data Units Read: 114,618,684 [58.6 TB] Data Units Written: 207,487,939 [106 TB] Host Read Commands: 383,008,645 Host Write Commands: 996,926,132 Controller Busy Time: 123,966 Power Cycles: 35 Power On Hours: 14,443 Unsafe Shutdowns: 19 Media and Data Integrity Errors: 0 Error Information Log Entries: 0 Warning Comp. Temperature Time: 0 Critical Comp. Temperature Time: 0 Temperature Sensor 2: 52 Celsius Error Information (NVMe Log 0x01, 16 of 64 entries) No Errors Logged Read Self-test Log failed: Invalid Field in Command (0x002) smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.12.24-Unraid] (local build) Copyright (C) 2002-23, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Model Number: KINGSTON SNV2S1000G Serial Number: 50026B7686B6899D Firmware Version: SBM02106 PCI Vendor/Subsystem ID: 0x2646 IEEE OUI Identifier: 0x0026b7 Controller ID: 1 NVMe Version: 1.4 Number of Namespaces: 1 Namespace 1 Size/Capacity: 1,000,204,886,016 [1.00 TB] Namespace 1 Formatted LBA Size: 512 Namespace 1 IEEE EUI-64: 0026b7 686b6899d5 Local Time is: Wed Apr 29 16:23:19 2026 EDT Firmware Updates (0x12): 1 Slot, no Reset required Optional Admin Commands (0x0016): Format Frmw_DL Self_Test Optional NVM Commands (0x009f): Comp Wr_Unc DS_Mngmt Wr_Zero Sav/Sel_Feat Verify Log Page Attributes (0x12): Cmd_Eff_Lg Pers_Ev_Lg Maximum Data Transfer Size: 64 Pages Warning Comp. Temp. Threshold: 83 Celsius Critical Comp. Temp. Threshold: 90 Celsius Supported Power States St Op Max Active Idle RL RT WL WT Ent_Lat Ex_Lat 0 + 5.00W - - 0 0 0 0 0 0 1 + 3.50W - - 1 1 1 1 0 200 2 + 2.50W - - 2 2 2 2 0 1000 3 - 1.50W - - 3 3 3 3 5000 5000 4 - 1.50W - - 4 4 4 4 20000 70000 Supported LBA Sizes (NSID 0x1) Id Fmt Data Metadt Rel_Perf 0 + 512 0 0 === START OF SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED SMART/Health Information (NVMe Log 0x02) Critical Warning: 0x00 Temperature: 33 Celsius Available Spare: 100% Available Spare Threshold: 10% Percentage Used: 19% Data Units Read: 75,048,809 [38.4 TB] Data Units Written: 205,472,724 [105 TB] Host Read Commands: 239,304,662 Host Write Commands: 988,904,080 Controller Busy Time: 122,383 Power Cycles: 27 Power On Hours: 14,249 Unsafe Shutdowns: 15 Media and Data Integrity Errors: 0 Error Information Log Entries: 0 Warning Comp. Temperature Time: 0 Critical Comp. Temperature Time: 0 Temperature Sensor 2: 57 Celsius Error Information (NVMe Log 0x01, 16 of 64 entries) No Errors Logged Read Self-test Log failed: Invalid Field in Command (0x002)

Hey all, Looking for advice/thoughts on a multitude of issues I've been having on my unraid server. I'll start with the most recent issue and then detail all of the others below. After 9 days of uptime, the web GUI became completely inaccessible (this is the third issue I've had over the past few weeks, more details below). Plex was still serving streams, SMB shares were accessible, all Docker containers were running normally - only the Unraid management layer (emhttpd/nginx) was dead. I plugged a monitor directly into the server and saw a kernel oops on screen. Was able to log in via the local console. System was otherwise fully functional. Hardware: ASUS PRIME B760M-A AX (BIOS 1646, March 2024) i7-12700K 32GB Corsair Dominator DDR5 2x16GB, running at stock 4800 MT/s, XMP disabled 4x Seagate Exos X18 18TB array drives + 2x parity 2x Kingston NV2 1TB NVMe cache (BTRFS RAID1) Sparkle Intel Arc A380 (currently removed from system, separate issue) Unraid 7.1.4, kernel 6.12.24 Background - three separate issues over the past few weeks. Detailing all just in case they may be related and anyone has information: Issue 1 - Hard kernel freezes (April 8-10, TESTING) Multiple complete hard freezes requiring hard resets. No network, no ping, no console, no peripheral power. Zero log evidence locally. Set up comprehensive monitoring writing to a Synology NAS every 10 seconds to survive crashes. Monitoring logs identified a potential cause - Plex VAAPI hardware transcoding via i915 on the Intel UHD 770 iGPU. Two concurrent VAAPI sessions triggered a GPU hang, kernel stalled waiting for GPU response, froze completely. I am testing disabling Plex hardware transcoding. System has ran stably for 9 days afterward. RAM ruled out - 18 passes Memtest86 across all configurations, 0 errors. Issue 2 - USB flash drive filesystem corruption (April 18) Web GUI went down, cron scripts started failing with exit 126, console was spammed with errors. System was still partially functional. Root cause was filesystem corruption on the USB boot drive (sda1) - the drive had been in a USB 3.0 port for ~2 years. Kernel logs showed: 2026-04-18T00:19:37 device offline error, dev sda, sector 2437240 op 0x0:(READ) 2026-04-18T00:19:37 device offline error, dev sda, sector 3110768 op 0x0:(READ) 2026-04-18T00:19:37 I/O error, dev loop1, sector 347456 op 0x0:(READ) 2026-04-18T00:19:37 SQUASHFS error: Failed to read block 0xa9a8308: -5 2026-04-18T00:19:37 SQUASHFS error: Unable to read fragment cache entry [a9a8308] 2026-04-18T00:19:37 device offline error, dev sda, sector 3607723 op 0x1:(WRITE) 2026-04-18T00:19:37 Buffer I/O error on dev sda1, logical block 3605675, lost async page write 2026-04-18T00:19:37 FAT-fs (sda1): unable to read inode block for updating (i_pos 55271939) 2026-04-18T00:19:37 FAT-fs (sda1): FAT read failed (blocknr 1777) 2026-04-18T00:19:37 FAT-fs (sda1): FAT read failed (blocknr 1776)Windows chkdsk found and repaired filesystem corruption. Drive moved to USB 2.0 port. System came back up cleanly. Hasn't had issues since. Issue 3 - smartctl_type kernel oops (April 25, current issue) After 9 days of clean uptime following the above fixes, the kernel oops described below occurred. What I think triggered it: The Dynamix system monitor is configured to refresh every minute (system="*/1 * * * *" in dynamix.cfg). As part of that refresh cycle it calls smartctl_type to update drive temperatures and stats on the dashboard. With 8 drives being polled every minute this gives frequent opportunities to hit whatever kernel bug is lurking in the mmap code path. Worth noting: both xe and i915 modules were loaded simultaneously at crash time - i915 for the iGPU, xe loaded by default on this kernel. Not sure if relevant but including it for completeness. Crash signature (from dmesg, April 25th 13:27:54): BUG: unable to handle page fault for address: ffffffffffffffff #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page Oops: Oops: 0010 [#1] PREEMPT SMP NOPTI CPU: 18 UID: 0 PID: 2458609 Comm: smartctl_type Tainted: P O 6.12.24-Unraid #1 Tainted: [P]=PROPRIETARY_MODULE, [O]=OOT_MODULE Hardware name: ASUS System Product Name/PRIME B760M-A AX, BIOS 1646 03/20/2024 RIP: 0010:0xffffffffffffffff Code: Unable to access opcode bytes at 0xffffffffffffffd5 Call Trace: <TASK> ? mast_split_data+0x3c/0x140 ? mas_push_data+0x1c6/0x210 ? mas_wr_bnode+0x417/0x4e0 ? mas_push_data+0x1e5/0x210 ? mas_store_prealloc+0x94/0xd0 ? vma_complete+0x7d/0x190 ? __split_vma+0x1c9/0x220 ? vms_gather_munmap_vmas+0x155/0x1d0 ? __mmap_region+0x216/0x700 ? mmap_region+0x72/0x90 ? do_mmap+0x43b/0x4a0 ? vm_mmap_pgoff+0xb6/0x110 ? ksys_mmap_pgoff+0x156/0x190 ? do_syscall_64+0x68/0xe0 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK> note: smartctl_type[2458609] exited with irqs disabledKey observations: The crash is entirely in kernel memory management code (mmap), not in smartctl itself. The instruction pointer jumped to 0xffffffffffffffff - an invalid address - suggesting a corrupted function pointer or use-after-free in the mmap code path. smartctl_type just happened to be the process that triggered it. This appears related to a pattern in the forums - the "6.12.8 - Segfaults and call traces" thread shows the same mmap crash signature appearing in smartctl_type, php-fpm, and python3 across different kernel versions. This suggests it's a recurring kernel mmap bug that manifests through different processes rather than being smartctl-specific. What happened after the crash: The oops killed smartctl_type which took emhttpd down with it. All containers, SMB shares, and network remained fully operational. Was able to log in via local console. Clean reboot restored everything. Previous forum thread for Issue 1 (hard freezes): https://forums.unraid.net/topic/198203-at-a-loss-unraid-keeps-crashing-and-no-logsevidenceartifacts-left-behind-are-helping-figure-it-out/ Diagnostics and full dmesg log attached. dmesg.log unraid-diagnostics-20260428-2341.zip

Update: I turned off Hardware Transcoding a week ago and it hasn't crashed since. This isn't necessarily conclusive because it's possible there's a race condition and this is coincidental, however, it seems likely that transcoding is the cause.

I haven't yet because it's a slow process lol. But that's on the list, yes! My next steps atm are: Run the server with HW transcoding on Plex turned off. If it doesn't freeze this may be the issue. If it does crash, check my logs. Depending on what they say I'll pivot from there. If no logs, I'll boot into Safe Mode and run Plex only. To cover all bases I also opened an RMA with my PSU manufacturer to see if they can send me a new one. Hard to prove it's a PSU but I basically said that I'm trying to rule everything out and the symptoms could be power.

@MowMdown Ah - right id need to be in 7.3 which I can't upgrade yet because my Unleashed sub ended but getting lifetime soon. If I don't resolve this by then I may try the xe driver. Not sure what to do next but to try and rule out transcoding I turned it off on Plex completely and I'm using software transcode to see if it still freezes. It's my main lead at the moment lol. The GPU appears to hang. Two concurrent Plex VAAPI sessions on the iGPU triggered i915 kernel stall right before the freeze from what I can tell. CPU was only at 20%, brief iowait spike, then complete hard lock with no panic or OOM. Kernel just stops responding waiting for the GPU. So idk... It's pointing to hw transcoding/GPU.

@MowMdown Okay, stupid question.... How did you do that?

I tend to agree that it would be odd that Plex is the issue, however, all of my evidence is pointing to that at the moment. When you say you're using the i915 and xe drivers what do you mean? You're using both?

https://www.reddit.com/r/unRAID/comments/1sgxuxn/comment/ofapee7/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button TLDR; It may be the i915 driver. I created my own bash scaript for verbose logging. Evidence from logs: top-processes.log - 18:38:27 (7 seconds before crash) 18:09 1:34 /app/bin/usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -hwaccel:0 vaapi -hwaccel_output_format:0 vaapi -hwaccel_device:0 vaapi -init_hw_device vaapi=vaapi:/dev/dri/renderD128,driver=iHD ... Plex was actively transcoding using VAAPI hardware acceleration on /dev/dri/renderD128 which is the Intel UHD 770 iGPU driven by the i915 driver. The transcode session started at 18:09 and had been running for 29 minutes before the crash. 2. docker-tautulli.log - concurrent sessions around crash 2026-04-10 18:09 - Plex Transcoder started - - VAAPI on renderD128 2026-04-10 18:33:53 - Session 2 started by user ******** 2026-04-10 18:33:59 - Session 2 is buffering 2026-04-10 18:38:34 - CRASHAt crash time there were two concurrent Plex transcode sessions running simultaneously. The movie had been transcoding via VAAPI for 29 minutes. A second user started a new session just 5 minutes before the crash. The second concurrent VAAPI session competing for iGPU resources likely pushed i915 over the edge and triggered the GPU hang. 3. system-resources.log - CPU spike at 18:38:06 top - 18:38:06 up 8:16, 1 user, load average: 0.69, 1.04, 1.09 %Cpu(s): 8.4 us, 7.9 sy, 0.0 ni, 79.4 id, 4.2 waSudden CPU spike with 4.2% iowait right before the crash. All other snapshots show 95-99% idle with near zero iowait. Consistent with a GPU hang causing a kernel stall. 4. memory.log - last entry 18:38:25 Fri Apr 10 18:38:25 EDT 2026 | Mem: 31Gi 9.8Gi 376Mi 1.2Gi 22Gi 21GiMemory completely normal right up to the crash. No OOM, no leak, no pressure. Rules out memory as the cause IMO. 5. docker-stats.log - 18:38:16 plex 2.98% 1.134GiB / 31.07GiB 3.65% V-Rising 12.12% 3.343GiB / 31.07GiB 10.76%All containers showing normal resource usage. Nothing runaway. 6. temperatures.log -18:38:12 All CPU cores 24-29°C, NVMe at 33°C. No thermal issues whatsoever. --- Every metric was completely normal except for the active VAAPI transcode sessions on the iGPU via i915. No OOM, no thermal event, no disk saturation, no runaway container. The system froze 7 seconds after the last log entry. The likely trigger was a second concurrent VAAPI transcode session starting 5 minutes before the crash, pushing the i915 driver into a state it couldn't recover from.

Alright. That can be my next steps after I do what I am currently doing. I restarted the stack and wrote a bash script that writes ALL logs to my NAS and polls every 5 seconds. Every docker container log, dmesg log, memory logs, pcie errors, temps, top processes, etc

Meaning, doing what I did and testing both sticks individually with memtest86 isnt sufficient and I should also test it with 1 stick at a time with the server running my stack?

UPDATE: Memtest86 has completed. Memtest86 - PASSED 10 Passes on both sticks of RAM - PASSED 4 Passes on each by themselves - PASSED

Well, shit. Was really hoping it was the GPU because I could RMA it. Sounds more and more like its memory. Damn it lol. Im going to let the parity check complete and then run a memtest to report back. Wonder if its a memory leak of some kind too with one of my containers. idk

Yeah, sorry about that. That's why I think it could be the card. But it could be that the card is still reporting it at x1 and thats what the dev was talking about? not sure...

Hmm. But I checked: lspci -vv -s 03:00.0 | grep "LnkSta:" and got "LnkSta: Speed 2.5GT/s, Width x1". Which is reading directly from the hardware. Unless the conversation you mentioned on discord is rerefrring to this specific cards GPU PCIe controller reporting it wrong? aka firmware?

Do you have any bug reports/posts/tickets etc that show that?

Nothing anymore as far as I am aware of but its been awhile since I installed it. Id have to check what its doing. Im currently checking the BIOs to see why the Arc a380 is running on x1 and not x16. Thats weird to me.

@trurl Honestly no idea. It seems inconsistent. It works, we use Plex to watch home media, seems fine. Then Ill go to check it because someone says Plex isnt working and then its not reachable. Display doesnt work even if i connect it to a monitor. Just hard stuck

Hey all - feeling defeated here... just no idea what's happening. Any help would be appreciated. Problem: 3 hard lock freezes. Complete kernel freeze - no network, no USB power, no display, no response. Requires hard reset. Hardware: ASUS PRIME B760M-A AX i7-12700K 32GB Corsair Dominator DDR5 (2x16GB, running at stock 4800 MT/s, XMP disabled) Intel Arc A380 ROG STRIX 650W Gold PSU 4x Seagate Exos X18 18TB array drives + 2x Seagate Exos 18TB parity 2x Kingston NV2 1TB NVMe cache (BTRFS RAID1) Unraid 7.1.4, kernel 6.12.24 What's I've checked: Drive health - all SMART clean, zero errors, SCT ERC correctly set to 70/70 on all 6 drives PSU - well within headroom PCIe/GPU - The odd thing here is I have a x16 card, but it shows its running in x1 mode in the GPU plugin... it's been working so no idea what this is about RAM speed - running stock DDR5 4800 MT/s, not overclocked Recent plugin updates - nothing suspicious correlates with crash timing Split lock warnings - appeared hours before crash, not correlated What's changed: I did just recently update all plugins/docker containers but no evidence of these causing issues Log evidence: Syslog (mirrored to Synology via remote syslog) ends cleanly each time with no kernel panic, no OOM, no trace - just stops. Last entry before crash 2 was monitor_nchan: Stop running nchan processes. No AER errors, no i915 errors, no disk errors in any log. UPDATE: Memtest86 has completed. Memtest86 - PASSED 10 Passes on both sticks of RAM - PASSED 4 Passes on each by themselves - PASSED unraid-diagnostics-20260409-1325.zip