I915 Error: GUC: TLB invalidation Causes OS to Hang

Ask Fedora
, ,
1

A number of users, including myself, have been experiencing an issue where the OS becomes unresponsive, nothing is clickable, but the mouse is still able to move. Rebooting the PC is required in order to restore functionality. This happens approximately once a day, often after waking from sleep. The journald error log is included below, as well as reports of this issue and attempted fixes from other users.

[begin: added 2025-07-25]

This issue was reported on i915 repo. At the time of writing, maintainers and users are still troubleshooting the issue.

[end: added 2025-07-25]

The maintainer of i915-sriov-dkms ([BUG] Kernel 6.5.7-200.fc38.x86_64, invalidation response timeout- crash when using virtualized gpu · Issue #118 · strongtz/i915-sriov-dkms · GitHub) traced the fix of this issue to drm/i915: CTB TLB invalidation fix on VM · intel/linux-intel-lts@c75552e · GitHub. The commit is summarized below:

The GuC firmware had defined the interface for Translation Look-Aside Buffer (TLB) invalidation. We should use this interface when invalidating the engine and GuC TLBs. Add additional functionality to intel_gt_invalidate_tlb, invalidating the GuC TLBs and falling back to GT invalidation when the GuC is disabled. The invalidation is done by sending a request directly to the GuC tlb_lookup that invalidates the table. The invalidation is submitted as a wait request and is performed in the CT event handler. This means we cannot perform this TLB invalidation path if the CT is not enabled. If the request isn’t fulfilled in two seconds, this would constitute an error in the invalidation as that would constitute either a lost request or a severe GuC overload.
With this new invalidation routine, we can perform GuC-based GGTT invalidations. GuC-based GGTT invalidation is incompatible with MMIO invalidation so we should not perform MMIO invalidation when GuC-based GGTT invalidation is expected.

What would be the best course of action to resolve this issue for regular users, ideally without rebuilding the kernel?

System Info
OS: Fedora Linux 42 (Workstation Edition)
Firmware Version: R2DET38W (1.23 )
Kernel Version: Linux 6.14.11-300.fc42.x86_64
Windowing System: Wayland
CPU: Intel Core Ultra 7 155H
iGPU: Intel Arc™ graphics
GPU: NVIDIA RTX 500 Ada Generation Laptop GPU 4GB GDDR6 (Nvidia driver installed)

journald error log when OS becomes unresponsive:


Jul 02 16:16:33 fedora kernel: i915 0000:00:02.0: [drm] *ERROR* GT0: GUC: TLB invalidation response timed out for seqno 85162
Jul 02 16:16:35 fedora kernel: i915 0000:00:02.0: [drm] *ERROR* GT0: GUC: TLB invalidation response timed out for seqno 85163
Jul 02 16:16:38 fedora kernel: i915 0000:00:02.0: [drm] *ERROR* GT0: GUC: TLB invalidation response timed out for seqno 85165
Jul 02 16:16:38 fedora kernel: i915 0000:00:02.0: [drm] *ERROR* GT0: GUC: TLB invalidation response timed out for seqno 85164
Jul 02 16:16:39 fedora kernel: Fence expiration time out i915-0000:00:02.0:gnome-shell[3281]:92f2!
Jul 02 16:16:40 fedora kernel: i915 0000:00:02.0: [drm] *ERROR* GT0: GUC: TLB invalidation response timed out for seqno 85167
Jul 02 16:16:40 fedora kernel: i915 0000:00:02.0: [drm] *ERROR* GT0: GUC: TLB invalidation response timed out for seqno 85166
Jul 02 16:16:42 fedora kernel: i915 0000:00:02.0: [drm] *ERROR* GT0: GUC: TLB invalidation response timed out for seqno 85168
Jul 02 16:16:42 fedora kernel: i915 0000:00:02.0: [drm] *ERROR* GT0: GUC: TLB invalidation response timed out for seqno 85169
Jul 02 16:16:44 fedora kernel: i915 0000:00:02.0: [drm] *ERROR* GT0: GUC: TLB invalidation response timed out for seqno 85170
Jul 02 16:16:46 fedora kernel: i915 0000:00:02.0: [drm] *ERROR* GT0: GUC: TLB invalidation response timed out for seqno 85171
Jul 02 16:16:47 fedora kernel: i915 0000:00:02.0: [drm] GPU HANG: ecode 12:0:00000000
Jul 02 16:16:47 fedora kernel: i915 0000:00:02.0: [drm] GT0: Resetting chip for stopped heartbeat on rcs0
Jul 02 16:16:47 fedora kernel: i915 0000:00:02.0: [drm] GT0: GuC firmware i915/mtl_guc_70.bin version 70.44.1
Jul 02 16:16:47 fedora kernel: i915 0000:00:02.0: [drm] GT0: GUC: submission enabled
Jul 02 16:16:47 fedora kernel: i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled

Reports of this issue have been made around the web, including attempts to resolve it, but none were successful. They are documented below:

1 Like
2

Did it actually disable GuC in dmesg? That’s what I would have tried first, but maybe newer GPUs require GuC and can’t disable it like that?

I’d try disabling IOMMU and CPU virt in BIOS too.

3

Hi there…

Lastly I’m experiencing many freezes and I’m trying to find the culprit.. And in order to narrow it down I’m trying to use as less software as possible.

I have definitely issues when running only Brave Browser…

But also when running nothing else than the terminal from a fresh boot.. Only running journalctl for example.

By grepping journalctl with error|bug I was able to see many errors related to i915 including the one from this post.

What can I try in my case?

I have an Asus laptop with Intel 285H CPU..

4

Hi everyone,

Have you tried to login via ssh and restart gdm? I’m just trying to figure out if the issue is related to mine.

6

Based on suggestions from several users, I replaced i915 driver with xe and the nvidia driver with nouveau, and this has somewhat reduced the frequency of hangs – it still occurs once in a while. It is unclear whether one or both driver replacements helped.

I also updated the post with a link to the issue in the i915 github repo in case anyone wish to track the troubleshooting progress.

8

Hi everyone once again. Could you please share a little bit more information about which kernel versions are affected on your hardware, and also - is it possible to restore the system with systemctl restart gdm.service?
This can actually help to identify the bug. My first kernel version affected was 6.12.8, but I’m pretty sure the bug was introduced in 6.12.
This could help to find the wrong commit. Thank you in advance!

9

Hi there and thanks for updating the discussion..

Can you explain how I can replace i915 with xe?

On my side I don’t have Nvidia GPU..

But my laptop is really unusable anymore as it crashes as soon as I open some apps (almost all electron app) but also just gnome app like the terminal..

Edit: I found that a way to do so is by setting i915.force_probe=!7d51 xe.force_probe=7d51 (7d51 being the PCI ID of my card)

Edit2: In my case using xe is definitely more stable but my laptop is still crashing (with only option to hard reboot) but it’s happening after a while (like 15 to 30 minutes?) instead of after couple of minutes and even seconds sometimes with i915..

I really don’t understand what happened to my laptop..

10

Which version of kernel are you using?

11

I had only two kernels in my grub list (not sure why it’s not the usual 3) 6.15.5 and 6.15.7

I was also able to install (using Koji) the kernel 6.11.11 (latest 6.11 kernel) as I read above that 6.12 might be the one introducing the bug.

But it crashed the same way.. Stable at first and e.g. opening obsidian (electron app) I instantly got a freeze with only the hard reboot (no TTY working).

I guess I’ll try with Xorg as I read it might be because of Wayland..

12

I don’t think downgrading the kernel makes sense in your case. It looks like the issues are completely different.

However, could you please try connecting via SSH from another machine and save the logs the next time it crashes?
sudo dmesg > dmesg
sudo cat /sys/class/drm/card1/error > error
(the card number may be different)

1 Like
13

Thanks for your time!
Sure, I’ll try to set up ssh from my phone (as I don’t have a second computer).
These dmesg and card from above is from the current “crashed” session of I’m able to log in using ssh, right?

Otherwise as I am able to see previous logs from the gnome Logs app or simply using journalctl -b -1 I’ll put that if you think it can be useful..

14

Yep. I think we must check if the system completely dead or not, and also grab card error state.

1 Like
15

Okay, I was able to successfully ssh from my phone…

Then I ssh’ed out, and ran obsidian (because I know it’s triggering the crash almost instantly, but it’s also true for many other programs).

And indeed my laptop crashed immediately.. But unfortunately I’m not able to ssh back into it.

Screenshot from Termux app on my phone:

1000047896
10000478961080Ă—569 46.5 KB

I’m going to boot using xe and update you with the journalctl of previous boot..

16

Well, this means your bug is quite different. I believe you shall create a separate issue for Intel.

17

I guess this is what I’ll do, although I don’t know what to point out…

Something interesting happened in my current boot session..
When I opened brave in order to post the log, it crashed but it only logged me out..
I was able to log back in.. It did it a second time, even..

So I guess it’s something different (although currently running xe, might be it..)

Is it okay to share journalctl output here (using ``` ``` maybe?)

PS: I can also log the current boot session.. I’m using Firefox btw.. So the issue seems definitely related around electron app… How can I be sure and open a bug on the relevant repo?

PS2: Well my laptop crashed again using Firefox.. I was not using Firefox but I used it just because it was already installed.. The crashed happened when I tried to view a YouTube video.. Isn’t something related to drm with youtube ? The drm I’m seeing in journalctl, isn’t the same thing?
The journalctl of this will be interesting as it has the logged out event and this crash event as well..

18

journalctl output can be very useful when posted as pre-formatted text using triple backquotes as you suggest. Some suggestions:

  • Add no-hostname (we usually don’t need to see that, and it means more the important text can be missed from the end of long lines)
  • Cutting an pasting journalctl output often truncates lines and add > at the end to indicated there is more text. After finding a suitable filter, I just re-run the journalctl command-line with filters after adding |cat at the end so the long lines are wrapped.
  • If you have a predictable way to generate an error, run journalctl --follow ... in a new terminal and then trigger the error withteh GUI or from a different terminal.
1 Like
19

Hi there…
Sorry, I’m still replying here (I also made a new post) as right now my laptop crashed but somehow I still have control on the mouse cursor (which is moving) but nothing else..
So I tried to ssh, and I was able to do so.
I ran these two commands, but unfortunately the terminal I’m using on my phone don’t really allow me to save the output on a file.

But here is a screenshot.

1000047906
10000479061080Ă—2340 355 KB

20

Just use “>” to save any command output to a file.

21

Linux has many ways to preserve output from commands in a terminal. I’m so old that my first encounter with Unix was on a dumb CRT terminal. The free Linux Command Book was writen by a human and has been found useful by colleagues and students who needed use specialized command-line linux apps. In addition to > the tee command lets you the output:

% echo some outout
some outout
% echo some outout |tee saved_output.text
some outout
% cat saved_output.text 
some outout
22

I just get several times when I using Firefox on latest Ubuntu_25_4_x86, and the journalctl gives the same error.
Sometimes it would be recovered by the system automatically, gives the firefox dump tips.
As you type the keyboard during the freezing, the system freezing while last long time and I have never waited its recovers.
If you change the tty at the first time, it change to the another tty several seconds late, and you can login, and stop gnome shell.
But if you try to return tty2 without kill gnome shell, the freezing starts again, seen like the whole system dumping, and you can never change tty again, the only thing you can do is press the power button to shutdown the machine.