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

Edited April 10Apr 10 by cjlmediasolutions

10 minutes ago, cjlmediasolutions said:

What hasn't been tested:

• Memtest86 (RAM integrity)

Should do that.

How long does it run before crashing?

@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

What are you using NerdTools for?

9 minutes ago, trurl said:

What are you using NerdTools for?

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.

Not much point in speculating until after memtest

1 hour ago, cjlmediasolutions said:

why the Arc a380 is running on x1 and not x16. Thats weird to me.

Known reporting error by the driver.

Edited April 9Apr 9 by Kilrah

Just now, Kilrah said:

Known reporting error.

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

Was recently discussed on Discord with the author of the GPU stats plugin.

Edited April 9Apr 9 by Kilrah

3 minutes ago, Kilrah said:

Was recently discussed on Discord with the author of the GPU stats plugin.

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?

No, it was about intel_gpu_top, AFAIK lspci should be correct but you never said where you were getting the info until now.

Just now, Kilrah said:

No, it was about intel_gpu_top, AFAIK lspci should be correct but you never said where you were getting the info until now.

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...

Ah lspci is actually wrong too, and intel even have a page on it

https://www.intel.com/content/www/us/en/support/articles/000094587/graphics.html

3 minutes ago, Kilrah said:

Ah lspci is actually wrong too, and intel even have a page on it

https://www.intel.com/content/www/us/en/support/articles/000094587/graphics.html

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

I can confirm the GPU reports incorrectly the link speed. My A310 always shows x1 as well regardless of what it's doing.

If there's nothing logged it's typically hardware issue, one thing you can try is to boot the server in safe mode with all docker containers/VMs disabled, let it run as a basic NAS for a few days, if it still crashes it's likely a hardware problem, if it doesn't start turning on the other services one by one, including the individual docker containers.

UPDATE: Memtest86 has completed.

Memtest86 - PASSED

• 10 Passes on both sticks of RAM - PASSED

• 4 Passes on each by themselves - PASSED

Note that memtest is only definitive if it finds errors, if you have multiple sticks you can try using the server with just one, if the same try with a different one, that will basically rule out bad RAM.

25 minutes ago, JorgeB said:

Note that memtest is only definitive if it finds errors, if you have multiple sticks you can try using the server with just one, if the same try with a different one, that will basically rule out bad RAM.

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?

That is what I would recommend to more confidently rule out the RAM. There have been multiple confirmed cases of memtest not detecting bad RAM.

3 minutes ago, JorgeB said:

That is what I would recommend to more confidently rule out the RAM. There have been multiple confirmed cases of memtest not detecting bad RAM.

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

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:

1. 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 - CRASH

At 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 wa

Sudden 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 21Gi

Memory 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.

I ran 3 simultaneous transcodes using my A310 and the i915 drivers with plex 1.43.1.10611 for about 20 minutes and zero crashes or unraid going unresponsive, whatever your issue is I do not suspect it is caused by plex.

Ive also been using Xe drivers as well, no issues.

Edited April 11Apr 11 by MowMdown

4 hours ago, cjlmediasolutions said:

UPDATE: Memtest86 has completed.

Memtest86 - PASSED

• 10 Passes on both sticks of RAM - PASSED

• 4 Passes on e

22 minutes ago, JorgeB said:

Note that memtest is only definitive if it finds errors, if you have multiple sticks you can try using the server with just one, if the same try with a different one, that will basically rule out bad RAM.

22 minutes ago, JorgeB said:

Note that memtest is only definitive if it finds errors, if you have multiple sticks you can try using the server with just one, if the same try with a different one, that will basically rule out bad RAM.

16 minutes ago, MowMdown said:

I ran 3 simultaneous transcodes using my A310 and the i915 drivers with plex 1.43.1.10611 for about 20 minutes and zero crashes or unraid going unresponsive, whatever your issue is I do not suspect it is caused by plex.

Ive also been using Xe drivers as well, no issues.

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?

@cjlmediasolutions Yes I was running the Xe drivers and switched back to i915 to test this specifically.