Finally, i made PLEX totally work by changing from Ubuntu OS to ArchLinux.
- HW works.
- HDR tone Mapping works.
- Test it for a WEEK, No Crush, No GPU hang, i915 function properly.
Let me know if you need any help.
1 Like
Go on then.
What CPU do you have?
Which version of Arch did you use?
- CPU: Intel(R) NUC11PAHi5 , BIOS PATGL357.0039.2021.0224.1510 02/24/2021, 11th Gen Intel(R) Core™ i5-1135G7 @ 2.40GHz
- GPU: Iris XE
- ArchLinux: Version: 2021.05.01 . Kernel: Linux archlinux 5.12.8-arch1-1
- Intel graphics driver & VA-API Driver: intel-media-driver.
1 Like
I fully expected you to say you had a desktop chip. 
This looks promising I’ll give it a go and report back. Expect it’s the 5.12.8 that did it.
Thank you for the update!
@turfrider Have you tried this yet, I’d like to know if this might actually solve this issue.
Hmm, this very important information on Plex not hardware transcoding 4K HDR on Windows with the i5-1135G7 NUC is hidden in a “server-linux” tagged thread. 
I think a lot of people have ordered NUC11s and similar new hardware just for using the Tiger Lake QuickSync capabilities with Plex. Can anyone else confirm that QSV HW acceleration with Plex on Windows is really not working (at the moment)?! Or has someone got it working? Sorry to post this in this only server-linux tagged thread, but I see a lot of the discussion here branching out to Windows as well.
1 Like
Are there any threads regarding Windows and NUC11 transcode issues? No? Well there’s your answer. One user already tried straying off topic, I suggest you use your Google-Fu a little more next time.
That was not really helpful, but thanks anyway.
Yes there is another thread, specifically regarding tone mapping issues. It gives more questions than answers in combination with the post I replied to.
I’ve googled repeatedly for information on this for months now and follow several NUC and Plex forums. Almost everyone is still waiting for the NUC 11s they’ve pre-ordered back in February-March, so it would be very interesting to hear from someone who has actually had the opportunity to try things out.
I wonder if the author of the post I replied to tried with/without tone mapping. And also what was the actual result besides “HWA will not work”, which doesn’t really rhyme with the other report. Hence the request for further information/datapoints.
1 Like
I just upgraded my NUC 11 to Ubuntu 21.04, to be able to get this famous 5.12 kernel.
It has dependency on a newer version of libc6, so bad idea to try to upgrade it on focal.
I kept the Intel Media packages installed, even if now they cannot be upgraded without the repo trick above (because Intel’s repo is for focal, not groovy or here hirsute).
Anyway, the default kernel for hirsute is 5.11.x, and it has the same issues. same crashes as 5.10.x on focal I then tried to install the latest mainline kernel, 5.12.9.
I had hard issues with Secure Boot, and was unable to sign myself the kernel with update-secureboot-policy --new-key, --enroll-key then sbsign (there’s a few pages about this on Internet, but they didn’t work in my case).
I had to reset with mokutil --reset because of weird messages in grub.
At the end I gave up and disabled Secure Boot. Very angry about this, I don’t understand why is it so hard to have Secure Boot enabled in Linux and deal with it, instead of “disable it, it’s useless”.
Moving on, after secure boot was disabled, I was able to boot on 5.12.9 kernel, still with my enable_guc=2 kernel option (using low power transcoding is the ultimate goal of a NUC, so GuC/HuC has to work).
I started my tests, the sames I listed above, and it crashed. It just took a bit more time to make it crash (don’t make assumptions than having one transcoding successful is a full success).
@ChuckPa 's test file was quicker to make it crash.
I removed enable_guc option to not taint the kernel at all, same results.
What a piece a junk this NUC is…
The NUC boxes are fine machines.
Did you update the firmware (BIOS/UEFI) ?
Whatever you get, out of the box, it almost always need immediate updating.
Usually I update all firmwares (BIOS, drives, etc.) prior to any OS installation.
So I did for this one too, and it’s running on latest BIOS, which is very buggy…
Ah, so the BIOS itself is buggy? That’s not good.
COVID strikes again?
Visually the BIOS looks good (Intel has been quite skilled on this aspect since first EFI bioses), but you will encounter all sort of weirdness, it would be too long to list all…
But the worst is the fan curve settings: if you change the fan curve, even for Intel settings (quiet/balanced/cool), it could freak out and shut the fan off. The fan remains stopped after several reboots.
You have to wait for the CPU to reach max temp, triggering watch dog alert, and finally it will start again. Complete crap… Intel support said it’s caused by Ubuntu, but it happens in the BIOS screen!
I’m not impressed by the CPU temperature, even with an aggressive fan curve. It’s between 70 and 80 Celsius degrees at idle (got an i7-1165). I suppose this is why when you put very minor load to it the fan will ramp up easily to max speed very aggressively.
So Intel built an Edsel ? The OS doesn’t override the BIOS/Firmware. Not cool but given they aren’t really in the CPU business anymore ? 
What happens if you take the firmware and do hard Reset to Factory defaults then come in it again?
I had to do that with my NUC8’s (they even suggested it in the early days)
1 Like
I asked for an 4K HEVC HDR file and got immediately this (and no HW transcoding):
[ 271.226549] Plex Transcoder[6058]: segfault at 0 ip 00007f051d99a9ab sp 00007ffc2ccbb290 error 4 in libstdc++.so.6.0.29[7f051d986000+103000]
[ 271.226558] Code: 10 00 00 00 5d e9 05 35 ff ff 0f 1f 44 00 00 f3 0f 1e fa 0f b6 07 84 c0 75 4d 55 53 48 89 fb 48 83 ec 08 48 8b 05 0d 49 16 00 <80> 38 00 75 20 31 c0 ba 00 01 00 00 f0 0f b1 17 75 2e 48 83 c4 08
Exact same thing for every HDR file I tried to play, and CPU nearly maxed out (because of no HW support).
After disabling HDR tone mapping, I retest my same files, and as asual they succesfully transcode for a few moments 4K to 1080p/720p until the exact same error we have now for months :
[ 685.566849] i915 0000:00:02.0: [drm] Resetting vcs1 for preemption time out
[ 685.567572] i915 0000:00:02.0: [drm] *ERROR* vcs1 reset request timed out: {request: 00000001, RESET_CTL: 00000001}
[ 685.568936] i915 0000:00:02.0: [drm] GPU HANG: ecode 12:4:28fffffd, in Plex Transcoder [7294]
[ 696.927362] i915 0000:00:02.0: [drm] GPU HANG: ecode 12:4:28fffffd, in Plex Transcoder [7294]
[ 697.029664] i915 0000:00:02.0: [drm] Resetting vcs1 for stopped heartbeat on vcs1
[ 697.030380] i915 0000:00:02.0: [drm] *ERROR* vcs1 reset request timed out: {request: 00000001, RESET_CTL: 00000001}
[ 697.030530] i915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on vcs1
[ 697.132967] i915 0000:00:02.0: [drm] *ERROR* vcs1 reset request timed out: {request: 00000001, RESET_CTL: 00000001}
[ 697.133743] i915 0000:00:02.0: [drm] *ERROR* vcs1 reset request timed out: {request: 00000001, RESET_CTL: 00000001}
[ 697.135024] i915 0000:00:02.0: [drm] *ERROR* vcs1 reset request timed out: {request: 00000001, RESET_CTL: 00000001}
[ 697.154459] i915 0000:00:02.0: [drm] *ERROR* vcs1 reset request timed out: {request: 00000001, RESET_CTL: 00000001}
[ 697.155237] i915 0000:00:02.0: [drm] *ERROR* vcs1 reset request timed out: {request: 00000001, RESET_CTL: 00000001}
[ 697.156510] i915 0000:00:02.0: [drm] *ERROR* vcs1 reset request timed out: {request: 00000001, RESET_CTL: 00000001}
[ 697.182388] i915 0000:00:02.0: [drm] *ERROR* vcs1 reset request timed out: {request: 00000001, RESET_CTL: 00000001}
[ 697.183164] i915 0000:00:02.0: [drm] *ERROR* vcs1 reset request timed out: {request: 00000001, RESET_CTL: 00000001}
[ 697.184436] i915 0000:00:02.0: [drm] *ERROR* vcs1 reset request timed out: {request: 00000001, RESET_CTL: 00000001}
[ 697.222467] i915 0000:00:02.0: [drm] *ERROR* vcs1 reset request timed out: {request: 00000001, RESET_CTL: 00000001}
[ 697.223241] i915 0000:00:02.0: [drm] *ERROR* vcs1 reset request timed out: {request: 00000001, RESET_CTL: 00000001}
[ 697.224510] i915 0000:00:02.0: [drm] *ERROR* vcs1 reset request timed out: {request: 00000001, RESET_CTL: 00000001}
[ 697.225062] i915 0000:00:02.0: [drm] *ERROR* Failed to reset chip
[ 697.225090] i915 0000:00:02.0: [drm:add_taint_for_CI [i915]] CI tainted:0x9 by intel_gt_reset+0x187/0x1b0 [i915]
[ 697.328955] i915 0000:00:02.0: [drm] *ERROR* vcs1 reset request timed out: {request: 00000001, RESET_CTL: 00000001}
[ 697.329724] i915 0000:00:02.0: [drm] *ERROR* vcs1 reset request timed out: {request: 00000001, RESET_CTL: 00000001}
[ 697.331002] i915 0000:00:02.0: [drm] *ERROR* vcs1 reset request timed out: {request: 00000001, RESET_CTL: 00000001}
[ 697.331604] i915 0000:00:02.0: [drm] Plex Transcoder[7294] context reset due to GPU hang
Check your kernel versus that of the author who has success.
Repeat for the Intel Compute Runtime installed files.
Find and resolve the differences.
It looks like your kernel is not matching.
Same kernel, Linux sargeras 5.11.0-18-generic #19-Ubuntu SMP Fri May 7 14:22:03 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Every Intel GPGPU repo package purged and replaced by Ubuntu own ones.
Same Intel Compute Runtime release, Release 21.22.19967 · intel/compute-runtime · GitHub.
Something is not right with Tiger Lake, that’s the difference.
Those Tiger Lake GPU are even more powerful than the desktop ones (10nm/96 EUs vs 14nm/32 EUs), this is waste.
As we don’t test the same files, using different test procedures, there are too many variables to consider. I shared my tests a few posts above, and it has been consistent in catching instabilities, after a few seconds or a few minutes.
I relayed the work reported in that thread.
Perhaps it’s worth discussing further with the author directly in his thread?
Look what shows up recently (i’m sure it wasn’t there in April):
BIOS Update [PATGL357]
From changelog:
Fixed issue where fan speed was not changing compared to the CPU
temperature which lead into a system shutdown due to overheating.
caused by Ubuntu 
…
Now we have to wait until they empty their backlog:
Issues · drm / intel · GitLab
