Arch Linux User Repository

GCC13.1 is mainlined in arch, so this means znver4 support can kick off on this kernel. The graysky compile patches have been updated too.

This kernel now natively supports the znver4 arch, but this kernel will most likely keep working on all AMD ryzen hardware. It's better to be able to address certain small perks or issues per architecture now and in the future.

If you use znver3 based hardware, please use linux-amd-znver3
If you use znver2 based hardware, please use linux-amd-znver2
If you use raven based hardware, please use linux-amd-raven

GCC11.1 is mainlined in arch, so this means znver3 support can kick off on this kernel. The graysky compile patches have been updated too.

This kernel now natively supports the znver3 arch, but this kernel will most likely keep working on all AMD ryzen hardware. It's better to be able to address certain small perks or issues per architecture now and in the future.

If you use znver2 based hardware, please use linux-amd-znver2
If you use raven based hardware, please use linux-amd-raven

Tired of compiling? Use this binary repo instead! Add this at the end of /etc/pacman.conf :

[linuxkernels]
Server = http://nhameh.ovh/$repo/$arch
SigLevel = Optional TrustAll

Only problem is if I update the patch, your checksums will be wrong since I do not iterate the file name. This is why you should download the tagged version.

--- a/PKGBUILD  2021-07-22 07:59:31.000000000 -0400
+++ b/PKGBUILD  2021-07-22 08:04:48.755848604 -0400
@@ -2,6 +2,7 @@

 pkgbase=linux-amd
 _srcname=linux
+_gcc_more_v=20210610
 gitver=v5.13.4
 pkgver=5.13.v.4
 pkgrel=1
@@ -18,19 +19,14 @@ source=("git+https://git.kernel.org/pub/
         "${pkgbase}.preset"
         # linux package install directives for pacman
         'linux.install'
-   # patch from our graysky archlinux colleague
-   'https://raw.githubusercontent.com/graysky2/kernel_compiler_patch/master/more-uarches-for-kernel-5.8+.patch'
+        # patch from our graysky archlinux colleague
+        "more-uarches-$_gcc_more_v.tar.gz::https://github.com/graysky2/kernel_compiler_patch/archive/$_gcc_more_v.tar.gz"
 )
 sha256sums=('SKIP'
-            #config.x86_64
             'ee078906b01680f16eaa14ada5ccf57af7c0012665f273de4be985dc5452db98'
-            #.preset file
             '60c6ba602443e94a9eba3aeee9d194027d69bffaa428c6d055348ebf03681b5c'
-            #linux install file
             'd590e751ab4cf424b78fd0d57e53d187f07401a68c8b468d17a5f39a337dacf0'
-            #grayskypatch
-            'fa6cee9527d8e963d3398085d1862edc509a52e4540baec463edb8a9dd95bee0'
-)
+            '49750c51711e011786888a501fb8deef26da8bcabfa71e9ad3e85ed01e2f60ef')

 _kernelname=${pkgbase#linux}

@@ -51,6 +47,7 @@ prepare() {
   sed -i '2iexit 0' scripts/depmod.sh

   # Implement all packaged patches.
+  ln -s $srcdir/kernel_compiler_patch-$_gcc_more_v/more-uarches-for-kernel-5.8+.patch ../more-uarches-for-kernel-5.8+.patch
   msg2 "Implementing custom kernel patches"
   while read patch; do
    echo "Applying $patch"

@Graysky Thank you for bringing this to my attention!

I see no problem in referencing your original source in the PKGBUILD. For my upstream kernels this seems to be no problem, I already adapted the pipelines. I will now always download your latest kernel patch (master) from your git. For non upstream kernels its a bit trickier because my pipeline works more flexible with the gentoo git, since you can dynamicly pick kernelversions there by branchname. But I will still mention you there. Thanks again and if there is anything else, just let me know.

The patch you're shipping (5010_enable-cpu-optimizations-universal.patch) is my more-uarches-for-kernel-5.8+.patch:

It's fine to pull it from gentoo's git repo, just suggesting that you hit mine directly. Look at how linux-ck does it if you want to, or just keep using gentoo as your upstream source.

% md5sum 5010_enable-cpu-optimizations-universal.patch more-uarches-for-kernel-5.8+.patch
15bc6521aae3d5aaded3da70b95ba854  5010_enable-cpu-optimizations-universal.patch
15bc6521aae3d5aaded3da70b95ba854  more-uarches-for-kernel-5.8+.patch

Hello Graysky,

I use the patches on https://gitweb.gentoo.org/proj/linux-patches.git/, Are you maintaining those aswel, or? Are those the same?

You might want to link my compiler patch directly: https://github.com/graysky2/kernel_compiler_patch/tags

@webmeister In addition to what @eggz said, this kernel specifically omits certain features deemed unnecessary. For example, filesystem encryption is specifically disabled despite the encryption being compatible with AMD hardware.

@webmeister The config is based on my pickings, findings, and testing. Its not copy pasted from anywhere, so it will be impossible for me to give you any source except but myself. I took a look at almost every CONFIG line and researched it was still relevant for modern AMD hardware. My Friend NhaMeh (comaintainer) also assisted in this picking. This didn't sit well indeed with some people in the past searching for a vanillaarch 'drop in' replacement, but this is, for all intends and purposes, a custom kernel.

Now, for the reason why I stay away from 1:1 vanilla arch based configs, I will need to go back in the past. I started maintaining amd kernels because the vanilla config of arch linux was completely incompatible with amd and amdgpu hardware in the past (~2018) for months on end. Now I want to be very clear in this: Arch linux does not build or test anything on AMD hardware, atleast they didn't for a very large period. My kernels their intention is to keep an upstream kernel version compatible with specific amd hardware. Apperantly this was a very unique thing to do around 2018. Long story short: I will never release a kernel that doesn't run/work on AMD hardware. I'm sorry, but making a 1:1 "drop in" kernelconfig simply puts that fact into serious jeopardy.

And thank you so much for pointing out the mtune! its still an old reference. I'll fix it asap! Can't believe I missed that. Thanks again!!

Thanks for maintaining this. What is your config.x86_64 based on? I assumed, it would follow https://github.com/archlinux/svntogit-packages/blob/packages/linux/trunk/config more closely, but the diff is huge (which makes it difficult to use as a drop-in replacement).

Also, is there any reason it still says mtune=znver2 in the PKGBUILD?

Linux Kernel 5.13 git development log:

      amdgpu:
       - Revert GFX9/10 doorbell fixes, we just end up trading one bug for
         another

Yeah, totaly didn't see that one coming ..

5.13 Coming up.

I reverted the faulty "doorbell" (thats how they call it in the git...) commits to remove the idle bug as referenced in the linux-slim and linux-amd-znver2 aur comments