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

Linus Torvalds <[email protected]>
Newsgroups org.freedesktop.lists.intel-xe,org.freedesktop.lists.dri-devel
Message-ID <CAHk-=wjZbz8v3M+qtzdPvDSshRX=2Krg=ByHyWOW9g+uLQgVkw@mail.gmail.com>
On Thu, 20 Aug 2026 at 20:50, Linus Torvalds
<[email protected]> wrote:
>
> 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
*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.

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
don't know about - so somebody competent needs to look at it.

                 Linus
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.