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

matteoguglielmi · 2025-10-01 20:26:42

Again, I could crash it in less than 10 seconds using hashcat.

kernel:

[root@max:~]# uname -r
6.17.0-rc6-1-drm-intel-next-git-gcc7e1a9b596c

kashcat:

[root@max:~]# hashcat -b -m 15700
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.

Kernel /usr/share/hashcat/OpenCL/m15700-optimized.cl:
Optimized kernel requested, but not available or not required
Falling back to pure kernel

OpenCL API (OpenCL 3.0 ) - Platform #1 [Intel(R) Corporation]
=============================================================
* Device #01: Intel(R) Arc(TM) Graphics, 44828/89656 MB (2047 MB allocatable), 16MCU

Benchmark relevant options:
===========================
* --backend-devices-virtmulti=1
* --backend-devices-virthost=1
* --optimized-kernel-enable

----------------------------------------------------------------
* 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: 47005806592
             Assuming normal desktop activity, reducing estimate by 34%: 31023832350
             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

Started: Wed Oct  1 22:18:45 2025
Stopped: Wed Oct  1 22:19:01 2025

dmesg:

[root@max:~]# dmesg | tail -10
[    6.438867] Bluetooth: BNEP filters: protocol multicast
[    6.438871] Bluetooth: BNEP socket layer initialized
[    6.439973] Bluetooth: MGMT ver 1.23
[    6.446854] NET: Registered PF_ALG protocol family
[    6.505036] loop4: detected capacity change from 0 to 8
[    7.653902] ax88179_178a 2-4.4:1.0 net1: ax88179 - Link status is: 1
[    9.737671] igc 0000:56:00.0 net0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
[  195.946948] i915 0000:00:02.0: [drm] GPU HANG: ecode 12:10:85def5fa, in hashcat [1530]
[  195.946951] i915 0000:00:02.0: [drm] GPU error state saved to /sys/class/drm/card1/error
[  195.946954] i915 0000:00:02.0: [drm] hashcat[1530] context reset due to GPU hang

Last edited by matteoguglielmi (2025-10-02 06:14:06)

matteoguglielmi · 2025-10-03 12:23:53

I am now looking for answers here.

matteoguglielmi · 2025-10-06 08:52:54

I have now opened a support ticket directly with ASUS.

matteoguglielmi · 2025-10-07 12:57:14

ASUS support turned me down with a "We do not provide official support for Linux."

Thank you ASUS, I truly appreciate it.

seth · 2025-10-07 14:23:33

From the intel thread:

I still have, even with the 6.14.0-1008-intel kernel, the sudden disappearance (after a while) of the GPU load when monitoring it, for instance, with the intel_gpu_top command (see attached picture).
This anomaly is occurring with ANY Linux kernel I've tried so far.

Is the system stable on windows then? It's not just that you're ending up underpowered?
Can you remove/deactivate some power consumers (wifi, bluetooth, external devices etc) or try to run the CPU in powersaving mode?

bigchungus · 2025-11-02 18:55:48

I am also have a very similar issue.

I am running ubuntu however

Linux (Debian GNU/Linux 11)
Kernel 6.8.0-87-generic
CPU Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz
GPU Intel ARC A310

After 1 hour, some intel gpu stats stop reporting
After 4-5 hours, the system crashes by pinning the CPU using the system interrupts.

matteoguglielmi · 2025-11-06 12:21:28

Try installing the Intel kernel (vmlinuz-6.14.0-1008-intel).

See instructions in this post.

bigchungus · 2025-11-07 15:28:11

Yep, it made it worse haha, it crashes about 20 minutes after reboot.

matteoguglielmi · 2025-11-08 05:27:01

If you really want some help from the community, I suggest you to start posting way more details about your system, your GPU, what drivers you are using, what you have tried so far, etc.

Hahas won't get you very far.

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

nomorewindows · 2025-11-09 01:12:02

I seem to have one of these on the shelf. From the box it seems to be an Asus nuc 14 pro, but my vga is raptor lake u (a7ad). It has the hdmi label on the front. It has 96gb max memory. How much memory does your box have?

Nonetheless,

Same problem on Debian? Apparently solved. Have to register to see the whole thread.

https://forums.debian.net/viewtopic.php?t=161549

I think I remember some complaints about Asus and their firmware now that they've changed ownership or something like that.

Last edited by nomorewindows (2025-11-09 01:18:54)

nomorewindows · 2025-11-09 01:22:02

matteoguglielmi wrote:

I am now looking for answers here.

Support for nuc 7 through nuc 13 has been handed off to Asus.

Nuc 14 is still under intel?

seth · 2025-11-09 08:28:09

https://en.wikipedia.org/wiki/Next_Unit_of_Computing - NUC14 is a straight up an ASUS product, no need to transfer anything

nomorewindows · 2025-11-10 01:06:27

The 64 bit processor had a limit of 64gb of ram, so maybe multicore doesn't have that limitation, but that's defined by memory lines anyhow which most motherboards haven't been able to take full advantage of that previously.

nomorewindows · 2025-11-10 01:19:55

matteoguglielmi wrote:

If you really want some help from the community, I suggest you to start posting way more details about your system, your GPU, what drivers you are using, what you have tried so far, etc.
Hahas won't get you very far.

But if he's using Ubuntu, he'll have to get it from Ubuntu forums.

seth · 2025-11-10 08:51:45

The 64 bit processor had a limit of 64gb of ram

2^32/1024^3
2^64/1024^3

https://archlinux.org/packages/extra/x8 … qalculate/
http://en.wikipedia.org/wiki/Physical_Address_Extension
The CPU bit-width is typically (and certainly w/ 64bit) not the RAM limiting factor and 64GB would be addressable w/ 36 bits.

Edit: must have hit copy+paste in a very weird moment, injecting the post into itself…

Last edited by seth (2025-11-10 09:10:02)

matteoguglielmi · 2025-11-10 09:06:52

Both my NUC 14 Pros have 96gb of ram.

nomorewindows · 2025-11-17 03:51:13

matteoguglielmi wrote:

Both my NUC 14 Pros have 96gb of ram.

Did the debian forum help?

Maybe you could try freebsd without too much trouble? It also has hashcat. But you will need to install some drm packages to get the intel driver for it. BSD typically is it's own thing, maybe has a different whole philosophy and different results.

matteoguglielmi · 2025-11-17 09:46:04

My ASUS NUCs work well with Ubuntu and the ppa:kobuk-team/intel-graphics repo.

I don't care about hashcat since I only used it for triggering the GPU failure of the NUCs.

BSD is not an option for me.

nomorewindows · 2025-11-24 20:47:31

Not able to get freebsd to work with my gpu right now.

Installed all these drm and gpu and related firmwares but no X!

Well ok so much for that idea.

matteoguglielmi · 2025-11-26 07:39:34

FINAL UPDATE, HOPEFULLY!

It's been quite some time since I started using Ubuntu 24.04 to avoid the very weird bug.

So, I decided to give Arch another try since I prefer Arch as my daily driver over Ubuntu.

First I did upgrade the BIOS of both NUCs to the latest version provided by ASUS, then I ran a full package update on both NUCs, then I reinstalled the linux-lts kernel, then I rebooted everything, and then, to my complete surprise, both systems seem to be running stable now!

In other words, the very weird bug seems gone!

Moreover, in OBS, after enabling the advanced options for streaming, I found the Intel Quick Sync hardware acceleration option, which is further lowering the CPU load from 20% to 10% (previously OBS was using the hardware accelerated ffmpeg binary for video encoding).

Both memory and CPU temperatures have also gone down by about 5 to 10 degrees Celsius on average.

hashcat still fails when running the 15700 benchmark, but this time around it does not trigger/initiate the crash of the systems anymore (just like in Ubuntu).

Currently, I am still running a burn-in test on both NUCs, which includes streaming, playing YouTube videos, and running WebGL apps, all at the same time.

And for the amount of time the burn-in test has been running already, the very weird bug would have occurred by now! (BTW, I am using the i915 kernel driver).

I truly hope this is the end of the very weird bug which has delayed the usage of the NUCs with Arch Linux for about half a year.

#> dmesg | grep ' i915 '
[    1.832173] i915 0000:00:02.0: [drm] Found METEORLAKE (device ID 7d55) display version 14.00 stepping C0
[    1.833279] i915 0000:00:02.0: [drm] VT-d active for gfx access
[    1.940423] i915 0000:00:02.0: vgaarb: deactivate vga console
[    1.940488] i915 0000:00:02.0: [drm] Using Transparent Hugepages
[    1.956240] i915 0000:00:02.0: vgaarb: VGA decodes changed: olddecodes=io+mem,decodes=io+mem:owns=io+mem
[    1.966020] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/mtl_dmc.bin (v2.23)
[    2.002072] i915 0000:00:02.0: [drm] GT0: GuC firmware i915/mtl_guc_70.bin version 70.53.0
[    2.013465] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled
[    2.013467] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled
[    2.013673] i915 0000:00:02.0: [drm] GT0: GUC: RC enabled
[    2.018148] i915 0000:00:02.0: [drm] GT1: GuC firmware i915/mtl_guc_70.bin version 70.53.0
[    2.018151] i915 0000:00:02.0: [drm] GT1: HuC firmware i915/mtl_huc_gsc.bin version 8.5.4
[    2.042040] i915 0000:00:02.0: [drm] GT1: HuC: authenticated for clear media
[    2.042392] i915 0000:00:02.0: [drm] GT1: GUC: submission enabled
[    2.042393] i915 0000:00:02.0: [drm] GT1: GUC: SLPC enabled
[    2.042459] i915 0000:00:02.0: [drm] GT1: GUC: RC enabled
[    2.045190] i915 0000:00:02.0: [drm] Protected Xe Path (PXP) protected content support initialized
[    2.068239] [drm] Initialized i915 1.6.0 for 0000:00:02.0 on minor 1
[    2.184174] i915 0000:00:02.0: [drm] GT1: Loaded GSC firmware i915/mtl_gsc_1.bin (cv1.0, r102.1.15.1926, svn 1)
[    2.204607] i915 0000:00:02.0: [drm] GT1: HuC: authenticated for all workloads
[    2.433657] i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device
[  621.942790] i915 0000:00:02.0: [drm] Reducing the compressed framebuffer size. This may lead to less power savings than a non-reduced-size. Try to increase stolen memory size if available in BIOS.

Last edited by matteoguglielmi (2025-11-26 14:28:07)

seth · 2025-11-26 12:43:32

First I did upgrade the BIOS of both NUCs to the latest version provided by ASUS

For posterity and your fellow victims you might want to provide the details on that update (which was likely the critical step)

matteoguglielmi · 2025-11-27 06:09:21

VERY WEIRD BUG is SOLVED

My burn-in test was successful on both NUCs, with zero warning or error messages from the kernel over 10+ hours.

Currently, one has to follow the Intel graphics guide to enable Intel's Intel Quick Sync hardware acceleration of the 7d55 GPU (and probably other GPUs).

All the details about my NUCs were posted earlier in this thread.

# uname -r

6.12.59-1-lts

# dmidecode --string bios-version

RVMTLV57.0051.2025.1013.1556

# lsmod | grep i915

i915                 4583424  50
i2c_algo_bit           24576  2 xe,i915
drm_buddy              24576  2 xe,i915
ttm                   102400  3 drm_ttm_helper,xe,i915
intel_gtt              28672  1 i915
drm_display_helper    266240  2 xe,i915
cec                    90112  3 drm_display_helper,xe,i915
video                  81920  4 asus_wmi,asus_nb_wmi,xe,i915

# pacman -Q | grep -P 'intel|mesa|vulkan'

intel-compute-runtime 25.40.35563.4-4
intel-gmmlib 22.8.2-1
intel-gpu-tools 2.2-1
intel-graphics-compiler 1:2.20.3-1
intel-media-driver 25.3.4-1
intel-ucode 20251111-1
linux-firmware-intel 20251111-1
mesa 1:25.2.7-1
opencl-mesa 1:25.2.7-1
vulkan-icd-loader 1.4.328.1-1
vulkan-intel 1:25.2.7-1
vulkan-mesa-device-select 1:25.2.7-1

Cheers.

Last edited by matteoguglielmi (2025-11-27 06:09:58)

seth · 2025-11-27 08:05:48

\o/
Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.

Arch Linux

#26 2025-10-01 20:26:42

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

#27 2025-10-03 12:23:53

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

#28 2025-10-06 08:52:54

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

#29 2025-10-07 12:57:14

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

#30 2025-10-07 14:23:33

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

#31 2025-11-02 18:55:48

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

#32 2025-11-06 12:21:28

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

#33 2025-11-07 15:28:11

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

#34 2025-11-08 05:27:01

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

#35 2025-11-09 01:12:02

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

#36 2025-11-09 01:22:02

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

#37 2025-11-09 08:28:09

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

#38 2025-11-10 01:06:27

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

#39 2025-11-10 01:19:55

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

#40 2025-11-10 08:51:45

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

#41 2025-11-10 09:06:52

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

#42 2025-11-17 03:51:13

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

#43 2025-11-17 09:46:04

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

#44 2025-11-24 20:47:31

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

#45 2025-11-26 07:39:34

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

#46 2025-11-26 12:43:32

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

#47 2025-11-27 06:09:21

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

#48 2025-11-27 08:05:48

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

Board footer