Conversation

It's kind of interesting how many general Linux bugs and problems we're running into and fixing as Asahi. Nothing huge, but there's the whole >4K page support issue in random software (which we're pushing on purpose), BTI issues in mesa, lots of random kernel bugs...
3
768
A lot of this is really just "real people are now using Linux on a real, modern ARM64 platform". Up until now there just hasn't been anything *modern* running real distros and a near-upstream kernel. Apple machines are ARMv8.5-A, everything else desktop is stuck on <=ARMv8.2-A.
3
282
There's Raspberry Pi, but they run heavily forked kernels and until this year weren't even offering a 64-bit OS image, never mind recommending it (they still don't). Those CPUs are positively ancient (ARMv8-A), so they don't test any modern CPU features.
5
188
Same with the whole >4K page issue. Until now only Red Hat was shipping 64K pages on server systems. So of course it was desktop stuff that was broken with >4K (particularly Chromium, but also jemalloc/libunwind issues often hit desktop apps).
3
159
This is, by the way, why I haven't merged the 4K support patch into the Asahi kernel yet. People need to fix their software/distros. I don't want to give them excuses not to. Feel the pain, fix it, and we'll be better off. Besides, 16K is notably faster and almost always better.
4
215
Replying to
We had ppc64 64k pages for years and never got the software all fixed! Endless battle. We had a lot of sw hardcoded at build time. So the 64k Firefox would blow up on a 4k kernel etc.
2
8
Replying to and
It's often used in performance critical places so while page size is supposed to be fetched at runtime, it's impractical. We still need to find someone interested in working on 16k / 64k support for github.com/GrapheneOS/har which just involves setting up slab slot count for it.
1