I’m trying to diagnose recurring whole-host hard freezes on a Plex server. The recently a few times it has stopped responding have coincided with different Plex activities: first an HDHomeRun DVR recording, and most recently adding media to a QNAP share and rescanning the Plex library.
The machine has needed a physical power cycle to recover. During the latest freeze, Plex and SSH were both unreachable. After the power cycle, Plex started normally.
Hardware and software
- Intel NUC Kit NUC7i7DNHE, board/hardware version J85489-202
- Intel Core i7-8650U, integrated Intel UHD Graphics 620 (
8086:5917, revision 07)
- Kernel driver in use:
i915
- Ubuntu 26.04.1 LTS
- Linux kernel
7.0.0-38-generic
- BIOS:
DNKBLi7v.86A.0037.2018.0131.0828, dated 2018-01-31
- 32 GB RAM
- Two Samsung SSD 860 drives, each about 1 TB
- Plex Media Server currently
1.43.5.11029-6bf8af3f0
Plex storage
- Plex metadata:
/mnt/plex-fast/plex-meta, on /dev/sdb1 (ext4)
- Plex transcode directory:
/mnt/plex-fast/transcode
- Media on a QNAP :mounted read/write as NFS 4.1 over TCP
- NFS mount uses
hard, timeo=600, retrans=2
Recent incidents
- Plex was recording from an HDHomeRun when the server stopped responding. Plex logged the recording starting at 19:50:00 and the HDHomeRun stream starting about eight seconds later. The NUC was power-cycled. The tuner was an HDHR5-4DT on firmware
20260326. Plex also logged Unknown source type 'Amateur' during tuner discovery, but I don’t know whether that is relevant.
- October 21: I added to QNAP
media folder and manually rescanned the folder/library. The NUC again became unreachable and required a power cycle.
What the logs show for the latest freeze
- Plex Media Server logs show a
Scanning media folders activity at 08:56:46 BST, at 74.9% complete. The log was enumerating media on /home/plex/YYYZZ from the QNAP share.
- The current scan log did not show the newly added media files before it stopped.
- The previous boot’s last system journal entries were at about 08:51 BST. The last kernel messages included:
workqueue: output_poll_execute hogged CPU for >10000us 2051 times, consider switching to WQ_UNBOUND workqueue: i915_hpd_poll_init_work [i915] hogged CPU for >10000us 2051 times, consider switching to WQ_UNBOUND
- Earlier in the same boot, the same warnings appeared with smaller counts. There was also a
perf: interrupt took too long warning.
- The journal stopped without a clean shutdown entry. I found no logged OOM kill, NFS “server not responding” message, disk I/O error, or hung-task report before the log stopped.
- The previous boot’s final
sar sample, at 08:50, showed about 88.8% CPU idle and 0.15% I/O wait; run queue was 1. That sample is several minutes before the final Plex scan log.
- The prior-boot Plex log’s final timestamp was 08:56:46. The NUC was power-cycled later, at about 11:09 BST. I don’t know exactly when the host became unresponsive because the logs stop earlier.
- After reboot, Plex was active and returned HTTP 200 locally. Both the metadata SSD and NFS share mounted normally.
- SMART overall-health checks passed for both Samsung SSDs. No failed systemd units were reported after reboot.
- At the last check,
/sys/class/drm reported all display connectors disconnected.
- The kernel command line contains no i915 workaround parameters.
Version/update history
Plex was on 1.43.5.11029. Plex was temporarily rolled back to 1.43.4.10903, then later installed again as 1.43.5.11029-6bf8af3f0 from the signed Public APT repository. There was some earlier ambiguity because the same build had also been described as Beta. I don’t know whether the Plex build is related to the host freezes.
The normal Ubuntu repository candidate for linux-generic-hwe-26.04 was still 7.0.0-38.38, the same kernel version currently running. I have not yet tried i915.enable_dc=0, changed kernel parameters.
Recovery configuration
Plex is configured to restart after a Plex service failure, but this does not help when the entire host stops responding. The latest recovery was therefore a physical power cycle.
Questions
- Has anyone seen these
i915_hpd_poll_init_work / output_poll_execute warnings on UHD Graphics 620 or Kaby Lake-R systems with Ubuntu 26.04 and kernel 7.0.0-38?
- Could the i915 hotplug/display polling warnings plausibly be related to a headless NUC hard-freezing, even with all display connectors reporting disconnected?
- Would testing
i915.enable_dc=0 be a reasonable next step on this UHD 620 system? Are there specific risks or better diagnostic steps?
- Could a Plex library scan over this NFS 4.1 hard mount be exposing an NFS/kernel issue, even though there are no NFS timeout messages in the saved logs?
I have not established a root cause yet. The fact that both incidents happened during Plex activity is a correlation.
I have cleaned up this wall of text with AI, I hope its still understandable...