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