Re: drm: xe: Kernel-submitted job timed out

On Fri, Aug 21, 2026 at 09:47:53AM -0700, Linus Torvalds wrote:
> On Thu, 20 Aug 2026 at 20:50, Linus Torvalds
> <[email protected]> wrote:
> >

First, thanks for looking into this, and I apologize for the
inconvenience. I had gotten to the point where, based on my testing, I
had reasoned that there was memory corruption somewhere in Xe that was
writing garbage into the page tables, but without a reproducer I
couldn't determine exactly where it was occurring.

> > I committed the fix as commit 818bebeb63dd ("drm/xe: Don't hand out
> > the flat CCS storage as usable VRAM").
> 
> Note: that is most definitely a real fix, but it's not necessarily the
> *right* fix.
> 
> For example, I do not understand the old 128kB alignment at all. It
> not only was definitely the wrong way around, but it made no sense in
> the first place.
> 
> The comment for it said "SW must round up to nearest 128K" and the
> original broken commit seems to imply that thatt comes from some
> hardware document.
> 
> But the result isn't actually *used* for any hardware state, as far as
> I can tell. It's just used for "vram_size" (called "usable_size" in
> xe_vram_probe, which as far as I could tell is only used by the driver
> for the allocator.
> 
> So the whole thing was just complete garbage, and I don't understand

Yes, this is garbage and can corrupt memory.

> *why*. I may be missing something, but yesterday I was so fed up with
> the experience of spending 10+ hours debugging what ended up being a
> one-liner that I just committed it as-is.
> 

one-liners tend to be hardest ones to find, again thanks, apologize,
etc...

> Now I'm back after a night's sleep, bright-eyed and bushy-tailed, and
> still not really wanting to look at it, but at least wanting to tie
> down some loose ends.
> 
> So I just want somebody who actually knows the Xe driver to look at
> that thing. I only round down by 4k, not 128k. I think the 128k was
> simply wrong and nonsensical. But that number came from *somewhere*.
> 
> I claim that the old 128kB number cannot be sane for another reason:
> the other side of that
> 
>         if (GRAPHICS_VER(xe) >= 20) {
> 
> will return an offset that is at a 64k granularity, because that's
> apparently the hardware field definition.
> 
> But the point is that the return value of get_flat_ccs_offset()
> clearly is *not* 128kB-aligned and never was, so not only was the
> alignment done in the wrong direction, it was always entirely
> nonsensical. It cannot possibly be something that the allocator code
> then depends on.
> 
> Anyway. It all now works for me, and apparently reliably. But the
> keyword is "for me". I committed that thing because the old code was
> clearly garbage, and the new code worked.
> 
> But the new code may be garbage too - for some reason that I simply

It will pop an assert somewhere else in the code, but that is also
questionable.

> don't know about - so somebody competent needs to look at it.
>

We are looking into this now and get a proper backportable fix post
asap.

Matt

>                  Linus