[RESOLVED] Very Weird Bug: Intel Meteor Lake-P GPU Load Drops To 0%

matteoguglielmi · 2025-07-29 13:31:37

Hello,

what I am reporting in this post is a bug (I hope!) that I've never seen before for the way it presents itself.

To trigger it, I need to start streaming with OBS and wait for about 30 to 45 minutes.

After that amount of time, the very first (weird) manifestation or symptom of the bug is the absence of any GPU load (0%), as reported by tools like btop or intel_gpu_top.

Despite the apparent absence of GPU load, everything is still very much accelerated (sooth YouTube videos playback, smooth Twitch video streams, OBS still streaming at 60 fps, CPU load around 5%) but not for too long.

Usually it takes 5 more minutes before the system becomes totally unresponsive, with all applications shutting down one after the other.

I have never seen anything like this because there are no logs reporting the crash of the GPU.

System specs:

#> dmidecode --string system-product-name
NUC14RVH-B

#> lspci -nn | grep -i vga
00:02.0 VGA compatible controller [0300]: Intel Corporation Meteor Lake-P [Intel Arc Graphics] [8086:7d55] (rev 08)

#> uname -r
6.15.8-arch1-1

#> cat /etc/modprobe.d/i915.conf 
options i915 enable_guc=3

#> obs --version
OBS Studio - 31.1.1

Zero GPU Load Image

To reproduce the bug it is sufficient to start playing any channel on Twitch or Kick and let it run for about one hour.

EDIT #1: OBS is not causing the issue, it just accelerates its manifestation.

EDIT #2: I can confirm this is a bug (probably a kernel bug - I run linux-lts) since I own two NUC14s with the same Intel GPU and both are affected in exactly the same weird way (NUC13s are not affected, I have a couple of them too).

EDIT #3: I tested the NUC14 with both the latest linux and linux-lts kernels, and the bug is present in both.

EDIT #4: I tested the xe driver (regular kernel booted with i915.force_probe=!7d55 xe.force_probe=7d55, but the two NUC14 do crash real bad almost immediately after opening anything that uses the 7d55 GPU) .

If you own a NUC14 with such a GPU (7d55), please let me know if your GPU is affected by the same issue where the GPU load suddenly drops to 0% - (see btop image linked above where the GPU load suddenly drops to 0%).

Thank you.

Last edited by matteoguglielmi (2025-11-27 10:08:39)

matteoguglielmi · 2025-08-21 09:21:05

I have updated both NUC 14 Pro (NUC14RVH-B/NUC14RVHV7 and NUC14RVH-B/NUC14RVHU7) with the corresponding latest firmware from ASUS (RVMTLV57.0049.zip and ANRPL357.0038.zip) but the crashes keep happening.

The simplest way to reproduce the issue (disappearing GPU load using a simple tool such as btop for monitoring it) is to open a browser with this link https://webglsamples.org/field/field.html and let it run for a few hours.

First, the GPU load will disappear in about 1 hour, then the whole system will crash, suddenly becoming extremely unresponsive, in about 2 to 3 hours (please note that the more the GPU is loaded, the faster the system will crash).

This is so weird.

It is doubtful that I own two faulty brand-new NUCs.

Is there anyone who can test it on a NUC 14 Pro and let me know the results?

Thank you!

cat /etc/modprobe.d/i915.conf

options i915 enable_guc=3

Last edited by matteoguglielmi (2025-09-07 09:36:11)

matteoguglielmi · 2025-09-07 08:23:32

I still have not found a solution to the issue.

The problem is not related to the CPU and/or memory usage.

I did heavy burn tests of both the CPU and memory: the issue could never be triggered.

Instead, when burning the GPU with, for instance, hashcat (CLI tool only, no need of XOrg/Wayland):

pacman -S intel-compute-runtime hashcat; hashcat -b

the issue gets triggered within the first 30 minutes or so.

Again, the "bug" is quite subtle; first, the GPU load will drop to zero, and then, after a while, the entire system will crash, generating numerous "random" segfault messages for some of the running binaries on the system.

Ultimately, the system will become completely unstable, making it impossible to shut it down.

Is there anyone out there with an NUC 14 who can try reproducing the issue?

Thank you.

Last edited by matteoguglielmi (2025-09-07 08:29:12)

matteoguglielmi · 2025-09-07 09:57:04

Hashcat is now throwing out these errors:

----------------------------------------------------------------
* Hash-Mode 15700 (Ethereum Wallet, SCRYPT) [Iterations: 262144]
----------------------------------------------------------------

* Device #1: This system does not offer any reliable method to query actual free memory. Estimated base: 8919720064
             Assuming normal desktop activity, reducing estimate by 34%: 5887015242
             This can hurt performance drastically, especially on memory-heavy algorithms.
             You can adjust this percentage using --backend-devices-keepfree

clWaitForEvents(): CL_EXEC_STATUS_ERROR_FOR_EVENTS_IN_WAIT_LIST

clFinish(): CL_OUT_OF_RESOURCES

clEnqueueWriteBuffer(): CL_OUT_OF_RESOURCES

-----------------------------------------------
* Hash-Mode 22500 (MultiBit Classic .key (MD5))
-----------------------------------------------

clEnqueueWriteBuffer(): CL_OUT_OF_RESOURCES

...

and dmesg shows finally something (but not always):

[ 4854.823342] i915 0000:00:02.0: [drm] GPU HANG: ecode 12:10:85def5fa, in hashcat [1239]
[ 4854.823348] i915 0000:00:02.0: [drm] hashcat[1239] context reset due to GPU hang

seth · 2025-09-07 19:47:01

Do you have any of https://wiki.archlinux.org/title/GPGPU#Intel installed?
Is "enable_guc=3" critical to trigger this? Does it happen w/ explicit "enable_guc=0"?

matteoguglielmi · 2025-09-08 09:08:51

seth wrote:

Do you have any of https://wiki.archlinux.org/title/GPGPU#Intel installed?
Is "enable_guc=3" critical to trigger this? Does it happen w/ explicit "enable_guc=0"?

Yes, intel-compute-runtime is installed, and if I set enable_guc=0, hashcat -b does not even start:

hashcat (v7.1.2) starting in benchmark mode

Benchmarking uses hand-optimized kernel code by default.
You can use it in your cracking session by setting the -O option.
Note: Using optimized kernel code limits the maximum supported password length.
To disable the optimized kernel code in benchmark mode, use the -w option.

clGetPlatformIDs(): CL_PLATFORM_NOT_FOUND_KHR

ATTENTION! No OpenCL, HIP or CUDA compatible platform found.

You are probably missing the OpenCL, CUDA or HIP runtime installation.

* AMD GPUs on Linux require this driver:
  "AMD Radeon Software for Linux" with "ROCm"
* Intel and AMD CPUs require this runtime:
  "Intel CPU Runtime for OpenCL" or PoCL
* Intel GPUs require this driver:
  "Intel Graphics Compute Runtime" aka NEO
* NVIDIA GPUs require this runtime and driver:
  "NVIDIA CUDA Toolkit" (both runtime and driver included)

Started: Mon Sep  8 11:04:35 2025
Stopped: Mon Sep  8 11:04:35 2025

Last edited by matteoguglielmi (2025-09-08 12:46:31)

seth · 2025-09-08 15:16:57

Do you get the same w/ https://archlinux.org/packages/extra/x8 … encl-mesa/ ?
(Symptoms sound like memory leak)

matteoguglielmi · 2025-09-11 11:28:00

Yes, same issue.

I have tested again the xe driver, and to my surprise, it now lasts a bit longer before crashing the system, so there was a little improvement there.

Anyway,

The current status is that both kernel drivers (i915 and xe) do not work (in my case) with my GPU:

00:02.0 VGA compatible controller [0300]: Intel Corporation Meteor Lake-P [Intel Arc Graphics] [8086:7d55] (rev 08)

that is installed in two different ASUS NUC 14 Pro (NUC14RVH-B/NUC14RVHV7 and NUC14RVH-B/NUC14RVHU7).

If you happen to have the same GPU (8086:7d55), please test it as described in this thread and let me know.

Thank you.

Last edited by matteoguglielmi (2025-09-11 11:28:55)

greenfoo · 2025-09-11 15:40:45

I was able to replicate this issue on a Dell Latitude 7450, with a similar GPU (8086:7d45 instead of 8086:7d55).
In my case, if I run this command, I start getting errors in less than 5 minutes:

$ hashcat -b
hashcat (v7.1.2) starting in benchmark mode
...
* Device #1: This system does not offer any reliable method to query actual free memory. Estimated base: 15307964416
             Assuming normal desktop activity, reducing estimate by 34%: 10103256514
             This can hurt performance drastically, especially on memory-heavy algorithms.
             You can adjust this percentage using --backend-devices-keepfree

In order to add some more information: I found this thread while experiencing something different: while gaming, when pushing the GPU (ex: high resolution) I would notice that every ~1 minute the GPU power consumption (and FPS) would drop to zero for ~15 seconds (GPU reset?) and then recover. I originally suspected it was related to the windows manager and started this other discussion, but after more testing I now think it is more related to the GPU driver instead.

matteoguglielmi · 2025-09-11 18:31:37

Thanks for taking the time to replicate the issue!

I have done the same extensive tests on a few NUC 13 Pro and on a Topton mini PC with these Intel GPUs:

[8086:a7a1], [8086:a7a9]

All tests ran perfectly fine with the i915 driver, not a glitch there.

I also believe it's a driver problem, since the latest xe driver is already "better" than it was a month ago, when opening the browser here was enough to crash the NUC 14 right away.

With the latest xe driver, the NUC 14s now crash in about 30 minutes.

Therefore, to some extent, the i915 and xe drivers are now "equivalent" in terms of crashing the 14s in the same way and in about the same amount of time.

Last edited by matteoguglielmi (2025-09-13 07:59:00)

matteoguglielmi · 2025-09-18 20:31:30

With the latest xe driver (and/or GPU firmware used by it), I'm finally getting what seems to be a more meaningful error message when hashcat -b begins to fail:

[ 2030.657926] xe 0000:00:02.0: [drm] *ERROR* GT1: TLB invalidation fence timeout, seqno=278358 recv=278357

I have also found this and this thread, which (I think) describes the same issue I have.

As suggested, I will try playing with the BIOS settings.

Last edited by matteoguglielmi (2025-09-18 20:41:17)

matteoguglielmi · 2025-09-19 07:15:17

Here we go, recapping everything:

This is the kernel error message when running hashcat -b with the i915 driver:

[ 1552.810288] i915 0000:00:02.0: [drm] GPU HANG: ecode 12:10:85def5fa, in hashcat [3303]
[ 1552.810296] i915 0000:00:02.0: [drm] hashcat[3303] context reset due to GPU hang

This is the kernel error message when running hashcat -b with the xe driver:

[ 2030.657926] xe 0000:00:02.0: [drm] *ERROR* GT1: TLB invalidation fence timeout, seqno=278358 recv=278357

Playing with the BIOS settings and the following kernel options (see links in my previous post) didn't change a thing:

intel_iommu=off
intel_idle.max_cstate=1
i915.enable_dc=0
ahci.mobile_lpm_policy=1

Currently installed packages with which the usage of the Intel 7d55 GPU leads to a crash of the whole system with both the i915 and xe kernel drivers:

vulkan-intel-1:25.2.3-1
intel-media-driver-25.2.6-1
linux-firmware-intel-20250917-1
intel-graphics-compiler-1:2.18.5-1
intel-compute-runtime-25.35.35096.9-1

In my case, when the kernel throws out either of those error messages, the GPU load drops to 0% (the GPU does not reset itself, or it fails to do so), and soon after that, the whole system crashes unconditionally.

We are hanging here...

Last edited by matteoguglielmi (2025-09-19 07:32:06)

seth · 2025-09-19 09:22:59

Since this is spellbound to GUC, is this a regression?
The firmware is coming from https://archlinux.org/packages/core/any … are-intel/ and probably more important than the kernel (module) in this case.

matteoguglielmi · 2025-09-20 12:12:45

I have installed downgrade from AUR and issued:

downgrade --oldest linux-firmware-intel

which pulled in:

linux-firmware-intel-20250613.12fe085f-3-any.pkg.tar.zst

but the issue is still there.

Despite this, I have made some progress in finding a systematic way to crash my Intel 7d55 GPU with a single hashcat benchmark in a few seconds.

Here it is:

hashcat -b -m 15700

Please,

If you happen to have one of these recent Intel GPUs, just run this simple hashcat benchmark and let us know if your system is affected by the same weird bug.

Last edited by matteoguglielmi (2025-09-20 12:13:39)

seth · 2025-09-20 15:04:03

seth wrote:

Since this is spellbound to GUC, is this a regression?

Ie. is there a point in trying older firmwares at all?
(The linux-firmware package got recently split which is why the oldest package is from June, you can still access much older firmwares, though)

matteoguglielmi · 2025-09-23 07:51:29

I have now Installed Ubuntu 24.04 on an external USB-SSD.

On the first boot, I did a full upgrade of the OS and installed the following three packages:

apt install intel-gpu-tools intel-opencl-icd hashcat

After that, I rebooted the NUC 14 and started the following GPU burn test:

On each monitor, I have opened a separate Firefox window loading the WebGL Field test.

On all three monitors, the Field simulation was running stable at 60 fps with Grass set to lots.

At the same time, in a terminal, I started this while loop:

while true ; do hashcat -b ; done

Results:

After a short time, the kernel threw out these messages:

[  973.284666] i915 0000:00:02.0: Using 41-bit DMA addresses
[ 1007.605815] workqueue: delayed_fput hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND
[ 1043.736382] workqueue: delayed_fput hogged CPU for >10000us 5 times, consider switching to WQ_UNBOUND
[ 1046.095342] workqueue: delayed_fput hogged CPU for >10000us 7 times, consider switching to WQ_UNBOUND
[ 1097.002494] workqueue: delayed_fput hogged CPU for >10000us 11 times, consider switching to WQ_UNBOUND
[ 1205.815539] perf: interrupt took too long (2525 > 2500), lowering kernel.perf_event_max_sample_rate to 79000
[ 1229.998607] workqueue: delayed_fput hogged CPU for >10000us 19 times, consider switching to WQ_UNBOUND
[ 1261.079723] Fence expiration time out i915-0000:00:02.0:hashcat[9268]:2a58!

after which hashcat hung indefinitely without throwing out any error messages, but also without affecting the entire system.

In other words, the system remained stable and kept running the Field simulations for an entire day.

It's also worth noting that during this time, I kept restarting hashcat several times.

hashcat, again, was running fine until the Hash-Mode 1500, where it always hung without throwing out any error messages (but the kernel did).

To me, these new findings support the assumption that the 7d55 Intel GPU is not fully supported by the kernel driver or the firmware used by it.

More logs:

# by default, Ubuntu 24.04 uses the i915 kernel driver (not the xe driver) with the following Intel GPU firmware versions:

root@ubuntu:~# dmesg | grep -Pi ' i915| xe'
[    3.449033] i915 0000:00:02.0: [drm] Found meteorlake (device ID 7d55) integrated display version 14.00 stepping C0
[    3.450254] i915 0000:00:02.0: [drm] VT-d active for gfx access
[    3.520325] i915 0000:00:02.0: vgaarb: deactivate vga console
[    3.520354] i915 0000:00:02.0: [drm] Using Transparent Hugepages
[    3.533097] i915 0000:00:02.0: vgaarb: VGA decodes changed: olddecodes=io+mem,decodes=io+mem:owns=io+mem
[    3.541937] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/mtl_dmc.bin (v2.21)
[    3.564707] i915 0000:00:02.0: [drm] GT0: GuC firmware i915/mtl_guc_70.bin version 70.36.0
[    3.576676] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled
[    3.576680] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled
[    3.576888] i915 0000:00:02.0: [drm] GT0: GUC: RC enabled
[    3.581628] mei_gsc_proxy 0000:00:16.0-0f73db04-97ab-4125-b893-e904ad0d5464: bound 0000:00:02.0 (ops i915_gsc_proxy_component_ops [i915])
[    3.581971] i915 0000:00:02.0: [drm] GT1: GuC firmware i915/mtl_guc_70.bin version 70.36.0
[    3.581973] i915 0000:00:02.0: [drm] GT1: HuC firmware i915/mtl_huc_gsc.bin version 8.5.4
[    3.605008] i915 0000:00:02.0: [drm] GT1: HuC: authenticated for clear media
[    3.605368] i915 0000:00:02.0: [drm] GT1: GUC: submission enabled
[    3.605369] i915 0000:00:02.0: [drm] GT1: GUC: SLPC enabled
[    3.605434] i915 0000:00:02.0: [drm] GT1: GUC: RC enabled
[    3.607651] i915 0000:00:02.0: [drm] Protected Xe Path (PXP) protected content support initialized
[    3.631384] [drm] Initialized i915 1.6.0 for 0000:00:02.0 on minor 1
[    3.661314] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[    3.750598] i915 0000:00:02.0: [drm] GT1: Loaded GSC firmware i915/mtl_gsc_1.bin (cv1.0, r102.1.15.1926, svn 1)
[    3.767204] fbcon: i915drmfb (fb0) is primary device
[    3.767212] i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device
[    3.770905] i915 0000:00:02.0: [drm] GT1: HuC: authenticated for all workloads
[  973.284666] i915 0000:00:02.0: Using 41-bit DMA addresses
[ 1261.079723] Fence expiration time out i915-0000:00:02.0:hashcat[9268]:2a58!
[ 3427.488430] Fence expiration time out i915-0000:00:02.0:hashcat[15940]:2af8!
[ 3926.649936] Fence expiration time out i915-0000:00:02.0:hashcat[16594]:2918!
[ 4085.641893] Fence expiration time out i915-0000:00:02.0:hashcat[17023]:b58!

Next, I will try the ppa:kobuk-team/intel-graphics repo and see what happens.

Last edited by matteoguglielmi (2025-09-23 07:56:53)

matteoguglielmi · 2025-09-23 11:38:50

I followed this guide to install the ppa:kobuk-team/intel-graphics repository and tools:

add-apt-repository -y ppa:kobuk-team/intel-graphics

apt-get install -y libze-intel-gpu1 libze1 intel-metrics-discovery intel-opencl-icd clinfo intel-gsc

apt-get install -y intel-media-va-driver-non-free libmfx-gen1 libvpl2 libvpl-tools libva-glx2 va-driver-all vainfo

Note that the kernel had not been upgraded after running the commands mentioned above.

Despite this,

The most significant improvement concerning hashcat is that, although it still crashes when executing the same Hash-Mode 1500, it no longer hangs indefinitely there.

Instead, after the crash, hashcat skips all the remaining hash modes until the last one is reached and then quits.

At the same time, the kernel message:

[ 1261.079723] Fence expiration time out i915-0000:00:02.0:hashcat[9268]:2a58!

no longer appears in the kernel logs (and none of the i915 or xe error messages of the Arch Linux kernel either!).

Moreover, the GPU load no longer drops to 0%, and all other applications using the GPU, e.g., Firefox, keep running as expected, well after hashcat crash.

Therefore,

The only difference between a standard Ubuntu 24.04 installation and the repo installation is that the packages from the repo make hashcat no longer hang, and the Fence expiration time out i915 messages no longer appear.

The repo also provides an Intel kernel for Ubuntu 24.04, which can be installed as follows:

apt install linux-intel

However, I did not notice any further stability improvements regarding the use of the i915 driver.

To me,

This suggests that the Arch Linux LTS kernel (and the rolling one, as I also tried it during my early tests) has some ongoing issues with the Intel 7d55 GPU (and similar ones) because the Ubuntu 24.04 kernel appears to be way more stable (e.g. Firefox cannot crash my NUC 14 when booted on Ubuntu 24.04).

Please note that the GPU firmwares have not changed at all when installing the Intel kernel for Ubuntu:

root@ubuntu:~# uname -r
6.14.0-1007-intel

root@ubuntu:~# dmesg | grep -Pi ' i915| xe'
[    3.359026] i915 0000:00:02.0: [drm] Found meteorlake (device ID 7d55) integrated display version 14.00 stepping C0
[    3.360337] i915 0000:00:02.0: [drm] VT-d active for gfx access
[    3.444392] i915 0000:00:02.0: vgaarb: deactivate vga console
[    3.444421] i915 0000:00:02.0: [drm] Using Transparent Hugepages
[    3.457084] i915 0000:00:02.0: vgaarb: VGA decodes changed: olddecodes=io+mem,decodes=io+mem:owns=io+mem
[    3.466095] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/mtl_dmc.bin (v2.21)
[    3.489378] i915 0000:00:02.0: [drm] GT0: GuC firmware i915/mtl_guc_70.bin version 70.36.0
[    3.500642] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled
[    3.500643] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled
[    3.500851] i915 0000:00:02.0: [drm] GT0: GUC: RC enabled
[    3.505353] mei_gsc_proxy 0000:00:16.0-0f73db04-97ab-4125-b893-e904ad0d5464: bound 0000:00:02.0 (ops i915_gsc_proxy_component_ops [i915])
[    3.505679] i915 0000:00:02.0: [drm] GT1: GuC firmware i915/mtl_guc_70.bin version 70.36.0
[    3.505681] i915 0000:00:02.0: [drm] GT1: HuC firmware i915/mtl_huc_gsc.bin version 8.5.4
[    3.528995] i915 0000:00:02.0: [drm] GT1: HuC: authenticated for clear media
[    3.529342] i915 0000:00:02.0: [drm] GT1: GUC: submission enabled
[    3.529343] i915 0000:00:02.0: [drm] GT1: GUC: SLPC enabled
[    3.529406] i915 0000:00:02.0: [drm] GT1: GUC: RC enabled
[    3.531674] i915 0000:00:02.0: [drm] Protected Xe Path (PXP) protected content support initialized
[    3.556339] [drm] Initialized i915 1.6.0 for 0000:00:02.0 on minor 1
[    3.582243] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[    3.675086] i915 0000:00:02.0: [drm] GT1: Loaded GSC firmware i915/mtl_gsc_1.bin (cv1.0, r102.1.15.1926, svn 1)
[    3.695501] i915 0000:00:02.0: [drm] GT1: HuC: authenticated for all workloads
[    3.878937] fbcon: i915drmfb (fb0) is primary device
[    3.878942] i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device
[  219.975089] i915 0000:00:02.0: Using 41-bit DMA addresses

Are the maintainers of the Arch Linux LTS kernel (and rolling one) in this forum?

Last edited by matteoguglielmi (2025-09-23 13:06:19)

seth · 2025-09-23 12:56:17

Are the maintainers of the Arch Linux LTS kernel (and rolling one) in this forum?

No frequently, you'd file a bug against https://gitlab.archlinux.org/archlinux/ … x/-/issues but the kernel is pretty much the upstream one anyway, https://github.com/archlinux/linux/comm … 6.8-arch2/

You could try to downgrade to https://archive.archlinux.org/packages/ … kg.tar.zst

matteoguglielmi · 2025-09-25 08:29:36

I confirm that Ubuntu 24.04 (Desktop and Server), does support the latest Intel Arc GPUs, especially when the ppa:kobuk-team/intel-graphics repository is used.

I am currently dual-booting the NUC 14 with Ubuntu 24.04 and Arch.

Ubuntu's kernel driver i915 works very well with the 7d55 GPU.

No glitches whatsoever, and no weird system crashes anymore.

OBS runs smoothly even when Firefox, Chrome, and Edge are used simultaneously.

Additionally, I was able to stream flawlessly without interruptions for over 10 hours using OBS.

That was my primary goal, which led me to a temporary OS change.

Waiting for Arch to be as stable as Ubuntu.

Last edited by matteoguglielmi (2025-09-25 08:33:54)

seth · 2025-09-25 09:53:36

Have you tried the 6.14 kernel on arch?
You do understand that Ubuntu uses a much older kernel and this might be a regression and the it's more that Ubuntu will become as unstable as arch?

matteoguglielmi · 2025-09-25 12:50:49

The very same issue happens right away with kernel 6.14.10-arch1-1 when running Hash-Mode 15700 (Ethereum Wallet, SCRYPT):

hashcat -b -m 15700

[  307.032469] i915 0000:00:02.0: [drm] GPU HANG: ecode 12:10:85def5fa, in hashcat [1284]
[  307.032477] i915 0000:00:02.0: [drm] hashcat[1284] context reset due to GPU hang

With the very latest kernel, again the same thing, and the same thing again with all the many Arch kernels I tried.

seth · 2025-09-25 13:12:20

You can try https://aur.archlinux.org/packages/linux-drm-tip-git and also to chroot into the arch system from the ubuntu boot (to see whether this is more a kernel or a userspace issue)
For clarification reg. #17: the ubuntu system only works properly w/ the intel PPA? Or also OOTB?

matteoguglielmi · 2025-09-26 15:08:44

The kernel generated by linux-drm-tip-git crashes just like any other Arch kernel I tried, and hashcat refuses to even start (get_exec_path() failed.) after chrooting from Ubuntu to Arch.

Last edited by matteoguglielmi (2025-09-26 15:10:04)

matteoguglielmi · 2025-10-01 07:51:53

Errata corrige about Ubuntu 24.04 LTS's stock kernel and ppa:kobuk-team/intel-graphics's kernel (linux-intel), after having used the NUC 14 for a week or so.

Ubuntu's stock kernel (6.8.0-84-generic) still generates the following error message (but the NUC does not crash), which differs completely from all the Arch's kernel error messages I received during my tests:

[drm] *ERROR* Atomic update failure on pipe A

Instead, the kernel installed with the linux-intel package from the ppa:kobuk-team/intel-graphics repo generates no error messages at all.

# uname -r

6.14.0-1007-intel

Therefore, I am assuming that whatever patches the kobuk-team is eventually applying to the Linux kernel is what Arch is still missing.

The NUC 14 is rock solid when running the 6.14.0-1007-intel kernel.

Last edited by matteoguglielmi (2025-10-01 07:58:53)

seth · 2025-10-01 18:34:53

Arch just packages the main linux kernels, downstream patches are rare.
So whenever intel decides to upstream those patches arch will implicitly pick them up.
In the meantime, there's actually https://aur.archlinux.org/packages/linu … l-next-git which you could also try.

Arch Linux

#1 2025-07-29 13:31:37

[RESOLVED] Very Weird Bug: Intel Meteor Lake-P GPU Load Drops To 0%

#2 2025-08-21 09:21:05

Re: [RESOLVED] Very Weird Bug: Intel Meteor Lake-P GPU Load Drops To 0%

#3 2025-09-07 08:23:32

Re: [RESOLVED] Very Weird Bug: Intel Meteor Lake-P GPU Load Drops To 0%

#4 2025-09-07 09:57:04

Re: [RESOLVED] Very Weird Bug: Intel Meteor Lake-P GPU Load Drops To 0%

#5 2025-09-07 19:47:01

Re: [RESOLVED] Very Weird Bug: Intel Meteor Lake-P GPU Load Drops To 0%

#6 2025-09-08 09:08:51

Re: [RESOLVED] Very Weird Bug: Intel Meteor Lake-P GPU Load Drops To 0%

#7 2025-09-08 15:16:57

Re: [RESOLVED] Very Weird Bug: Intel Meteor Lake-P GPU Load Drops To 0%

#8 2025-09-11 11:28:00

Re: [RESOLVED] Very Weird Bug: Intel Meteor Lake-P GPU Load Drops To 0%

#9 2025-09-11 15:40:45

Re: [RESOLVED] Very Weird Bug: Intel Meteor Lake-P GPU Load Drops To 0%

#10 2025-09-11 18:31:37

Re: [RESOLVED] Very Weird Bug: Intel Meteor Lake-P GPU Load Drops To 0%

#11 2025-09-18 20:31:30

Re: [RESOLVED] Very Weird Bug: Intel Meteor Lake-P GPU Load Drops To 0%

#12 2025-09-19 07:15:17

Re: [RESOLVED] Very Weird Bug: Intel Meteor Lake-P GPU Load Drops To 0%

#13 2025-09-19 09:22:59

Re: [RESOLVED] Very Weird Bug: Intel Meteor Lake-P GPU Load Drops To 0%

#14 2025-09-20 12:12:45

Re: [RESOLVED] Very Weird Bug: Intel Meteor Lake-P GPU Load Drops To 0%

#15 2025-09-20 15:04:03

Re: [RESOLVED] Very Weird Bug: Intel Meteor Lake-P GPU Load Drops To 0%

#16 2025-09-23 07:51:29

Re: [RESOLVED] Very Weird Bug: Intel Meteor Lake-P GPU Load Drops To 0%

#17 2025-09-23 11:38:50

Re: [RESOLVED] Very Weird Bug: Intel Meteor Lake-P GPU Load Drops To 0%

#18 2025-09-23 12:56:17

Re: [RESOLVED] Very Weird Bug: Intel Meteor Lake-P GPU Load Drops To 0%

#19 2025-09-25 08:29:36

Re: [RESOLVED] Very Weird Bug: Intel Meteor Lake-P GPU Load Drops To 0%

#20 2025-09-25 09:53:36

Re: [RESOLVED] Very Weird Bug: Intel Meteor Lake-P GPU Load Drops To 0%

#21 2025-09-25 12:50:49

Re: [RESOLVED] Very Weird Bug: Intel Meteor Lake-P GPU Load Drops To 0%

#22 2025-09-25 13:12:20

Re: [RESOLVED] Very Weird Bug: Intel Meteor Lake-P GPU Load Drops To 0%

#23 2025-09-26 15:08:44

Re: [RESOLVED] Very Weird Bug: Intel Meteor Lake-P GPU Load Drops To 0%

#24 2025-10-01 07:51:53

Re: [RESOLVED] Very Weird Bug: Intel Meteor Lake-P GPU Load Drops To 0%

#25 2025-10-01 18:34:53

Re: [RESOLVED] Very Weird Bug: Intel Meteor Lake-P GPU Load Drops To 0%

Board footer