drm: xe: Kernel-submitted job timed out
drm: xe: Kernel-submitted job timed out
Linus Torvalds<br>torvalds at linux-foundation.org
Fri Aug 21 03:50:44 UTC 2026
Previous message (by thread): drm: xe: Kernel-submitted job timed out
Next message (by thread): [PATCH v4 0/5] powervr: MT8173 GPU support
Messages sorted by:<br>[ date ]<br>[ thread ]<br>[ subject ]<br>[ author ]
On Tue, 18 Aug 2026 at 23:55, Linus Torvalds<br>torvalds at linux-foundation.org> wrote:<br>> It turns out that now I can generate those drm job timedout issues at will.<br>> [ +1.222075] xe 0000:4b:00.0: [drm] Tile0: GT0: Engine reset:
Ok. I've spent all day today on chasing this down in between merge<br>window work, since it finally *was* repeatable.
And the fix ends up being basically a one-liner, even if the debug<br>session to get there was not.
The Xe driver takes the memory address used for the memory stolen for<br>CCS, and rounds it up to the nearest 128kB area.
And that is very VERY wrong, because it means that the xe driver will<br>then *use* that part of memory that wasn't at a 128kB boundary. And<br>the HW engine will too and write to it.
And when that memory happens ot be used for GPU page tables, very bad<br>things happen.
I bet this also explains some occasional random screen corruption I've<br>seen - when the memory isn't used for something as important as a page<br>table, it "only" corrupts random bitmap memory and the like.
I committed the fix as commit 818bebeb63dd ("drm/xe: Don't hand out<br>the flat CCS storage as usable VRAM").
Adding some people from commit 37173392741c ("drm/xe/vram: fix ccs<br>offset calculation") to the cc, because that's where the problem came<br>from. Two years ago. I'm not sure why it became so repeatable for me<br>now, but some user space behavior change clearly triggered it now<br>pretty much every single boot.
Linus
Previous message (by thread): drm: xe: Kernel-submitted job timed out
Next message (by thread): [PATCH v4 0/5] powervr: MT8173 GPU support
Messages sorted by:<br>[ date ]<br>[ thread ]<br>[ subject ]<br>[ author ]
More information about the dri-devel<br>mailing list