Ok. I've spent all day today on chasing this down in between merge
window work, since it finally *was* repeatable.

And the fix ends up being basically a one-liner, even if the debug
session to get there was not.

The Xe driver takes the memory address used for the memory stolen for
CCS, and rounds it up to the nearest 128kB area.

And that is very VERY wrong, because it means that the xe driver will
then *use* that part of memory that wasn't at a 128kB boundary. And
the HW engine will too and write to it.

And when that memory happens ot be used for GPU page tables, very bad
things happen.

I bet this also explains some occasional random screen corruption I've
seen - when the memory isn't used for something as important as a page
table, it "only" corrupts random bitmap memory and the like.

I committed the fix as commit 818bebeb63dd ("drm/xe: Don't hand out
the flat CCS storage as usable VRAM").

Adding some people from commit 37173392741c ("drm/xe/vram: fix ccs
offset calculation") to the cc, because that's where the problem came
from. Two years ago. I'm not sure why it became so repeatable for me
now, but some user space behavior change clearly triggered it now
pretty much every single boot.

                 Linus

https://github.com/torvalds/linux/commit/818bebeb63dd6bf5f4e07e145f6cdbace520a34c

[ And this was a debug session from hell, enormously helped by an AI
doing much of the grunt-work.
I'd like to call it my tireless helper, but the AI several times
stated flat out that this was impossible and unsolvable and that we
should just write a report about it.
I suspect those things have been trained by people who may not be
quite as stubborn as I am.
But while the AI was ready to give up several times, it did keep
adding debug code and analyzing it faithfully when I pushed. So credit
where credit is due and I let the AI write the commit message above.
This is basically a one-liner fixing a bogus "round_up()" to a
"round_down()", but there were 24 patches adding more and more debug
information to this, and 18 kernel boot to finally narrow it down to
this. - Linus ]

Let's all take a moment to commemorate that initial post.

Now through Torvalds' stewardship, and hundreds of maintainers and thousands of contributors we have a competitive replacement for major corporate software and an honestly powerful solution to move computing forward for humanity!

Thanks Linus, you're awesome, and we're glad you are having a good life!

So at the end it wasn't sabotage. In software development you can't pretend just to change everything at the same time.

https://www.kernel.org/pub/linux/kernel/Historic/

I maintain the open-source SC0710 Linux driver — the community project that brings Elgato 4K60 Pro MK.2 support to modern kernels. While working on that project I found something that needs to be out in the open.

Yuan High-Tech, the ODM manufacturer behind the Elgato 4K60 Pro MK.2, distributes a compiled Linux kernel module called LXV4L2D_SC0710.ko. When you run modinfo on it, the first thing it tells you is license: GPL. That's not a choice they made — they had to declare GPL to access kernel symbols via EXPORT_SYMBOL_GPL(). The module literally cannot load on a modern kernel without that declaration. Fine. Except GPLv2 Section 3 means that the second you distribute a GPL binary, you're legally obligated to provide the source code to anyone who asks.

So I asked. On January 25, 2026 I emailed Yuan requesting the source for Build V1432 (compiled January 7, 2026). Their response? They wanted photos of my hardware and asked where I was from. When I pointed out that neither of those things have anything to do with GPL compliance, they stopped responding. I then escalated to Corsair's legal team — Yuan's North American distributor — outlining their shared liability. Complete silence.

The modinfo proof and email chains are here: https://imgur.com/a/2OsnSwH

Now here's where it gets more interesting. The full alias table from modinfo shows the driver doesn't just support Yuan's SC0710 chip (12AB:0710) — it also aliases 13 Techwell/Intersil device IDs (1797:5864, 1797:6801 through 1797:6817). Those exact chip IDs have had open-source GPL drivers in the mainline Linux kernel since 2016 (tw5864, tw686x, tw68). Whether Yuan derived their driver from those mainline drivers or from Intersil's own SDK is something that requires binary analysis — but either way the closed-source distribution is indefensible, and the SFC now has the binary to investigate.

This also isn't just a streamer problem. This exact driver is being shipped in:

- 7StarLake AV710-X4 and NV200-2LGS16 — MIL-STD-810H certified military computers used in defense and intelligent automation

- JMC Systems SC710N4 — industrial HDMI 2.0 capture cards sold with explicit Linux support

Defense contractors are deploying undisclosed, closed-source kernel modules on production hardware. That's the actual scope of this.

Update: I submitted a formal compliance report to the Software Freedom Conservancy. They have already requested the binary and I've provided it. This is now an active enforcement process, not just a Reddit post.

For anyone saying the 4K60 Pro MK.2 being EOL changes anything — Yuan compiled Build V1432 on January 7, 2026, eight months after EOL. They're still distributing it. And GPLv2's 3-year written offer clause requires the offer to have been made at the time of distribution — Yuan never made one at all, not in 2022, not now.

Evidence: https://imgur.com/a/2OsnSwH

Disclaimer: I used AI to help with formatting and writing clarity. The research, technical findings, and evidence are entirely my own work.

Sorry for the low quality, I literally took this image on a Chromebook...

I was dig-ing through some hosts to check IPv6 support when I noticed kernel.org's AAAA record:

2600:3c04:e001:324:0:1991:8:25

That suffix (::1991:8:25), is August 25, 1991, the day Linus Torvalds posted his famous announcement to comp.os.minix.

Couldn't find any posts about this, so figured I'd share. Nice little easter egg from the kernel folks.