Arch Linux User Repository

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

Actually never mind, something messed up and so I'll just stick to the PKGBUILD. Thanks

How do we force "make localmodconfig" on your PKGBUILD?

I have it set to "menuconfig" so I can force zstd compress, but now the kernel, it build every module and the kitchen sink, was searching and didn't see an option where you would expect to see one?

Thanks for the thorough answer.

It sure does. This was enabled by default starting from version 5.0. It should be enabled anywhere. You can check if its working with these steps. (everybody loves some feedback)

1) add 'drm.debug=0x04' to your kernel parameters preferably in "/etc/default/grub", in the GRUB_CMDLINE_LINUX, like this: GRUB_CMDLINE_LINUX="drm.debug=0x04" and then run grub-mkconfig -o /boot/grub/grub.cfg

or directly in "/boot/grub/grub.cfg" at the 'linux /boot/vmlinuz-linux' line, something like this: linux /boot/vmlinuz-linux root=UUID=<uuid> rw drm.debug=0x04

2) monitor dmesg output for 'VRR'(variable refresh rate?) strings (when the DE starts or when doing something opengl);

log search: dmesg | grep -e drm -e VRR realtime monitor: dmesg -w | grep -e drm -e VRR

You should see something like:

[  316.044970] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] VRR packet update: crtc=77 enabled=0 state=2
[  316.058560] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] VRR packet update: crtc=80 enabled=0 state=2
[  319.678906] [drm:drm_mode_addfb2 [drm]] [FB:132]
[  319.679766] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] VRR packet update: crtc=77 enabled=1 state=3
[  319.683630] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] VRR packet update: crtc=80 enabled=1 state=3
[  319.740178] [drm:drm_mode_addfb2 [drm]] [FB:140]
[  319.763956] [drm:drm_mode_addfb2 [drm]] [FB:141]
[  322.578440] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] VRR packet update: crtc=77 enabled=0 state=2
[  322.589016] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] VRR packet update: crtc=80 enabled=0 state=2
[  342.316459] [drm:drm_mode_addfb2 [drm]] [FB:131]
[  342.317336] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] VRR packet update: crtc=77 enabled=1 state=3
[  342.331751] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] VRR packet update: crtc=80 enabled=1 state=3
[  342.387385] [drm:drm_mode_addfb2 [drm]] [FB:132]
[  342.413740] [drm:drm_mode_addfb2 [drm]] [FB:133]
[  352.512071] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] VRR packet update: crtc=77 enabled=0 state=2
[  352.522602] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] VRR packet update: crtc=80 enabled=0 state=2
[  354.964177] [drm:drm_mode_addfb2 [drm]] [FB:137]
[  354.965248] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] VRR packet update: crtc=77 enabled=1 state=3
[  354.968819] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] VRR packet update: crtc=80 enabled=1 state=3
[  355.024555] [drm:drm_mode_addfb2 [drm]] [FB:132]
[  355.051308] [drm:drm_mode_addfb2 [drm]] [FB:141]

the VRR packet updates will show you that freesync is doing its thing.

ADDITION: you can even check out the monitor(s?) freesync range(s?) with this command: cat /sys/kernel/debug/dri/0/DP-*/vrr_range

Initial support was for a single monitor only, but my tests show now it should always be working, atleast when you are using OGL fullscreen on some monitor.

Quick question, does this kernel come with freesync baked in and enabled?

5.11.2 still does not contain the upstream amdgpu fixes, but atleast they are spotted in the master tree of stable:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9c712c9c382ca69a955e3a384fc245ad8c42b005

Which leads me to believe they will finally be merged in 5.11.3

Until then, enjoy this prepatched kernel I guess..

Don't worry, there are no hard feelings - I hope I didn't sound rude :) As for the build pipeline: that's a valid point I didn't consider. It's just that your current PKGBUILD takes way longer than it could for everyone else (especially people with slow internet access).

I don't like binary builds (from the AUR) too much for critical things like the kernel, but I might give it a try.

Thank you for the fast response and for maintaining this project.

I'm Sorry, but that would break my entire build pipeline. I hope you don't take this personally..

You sound like a capable guy (since you don't want to use the binary repo), maybe you can, for example, "sed" my PKGBUILD to your likings before you fire the build? Shouldn't be that hard to automate that. I also love automation.

Could you please either change the retrieval of the source code to the tar archive like for examlpe the linux-clear package does or alternatively use something like git clone --depth 1 --branch $gitver https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git?

• https://aur.archlinux.org/packages/linux-clear/

It's completely unnecessary to retrieve the complete git history of the kernel (it wastes a lot of space when being kept in the cache directory and takes forever to download on a clean build).

Compare your current PKGBUILD:

[..]
Receiving objects: 100% (9277799/9277799), 3.43 GiB | 8.04 MiB/s, done.
[..]
dev@vm:~$ du -hs ~/.cache/yay/linux-amd-znver2/linux
3,7G    ~/.cache/yay/linux-amd-znver2/linux

Using only the current/required state (--depth 1):

dev@vm:~$ git clone --depth 1 --branch v5.11.1 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
[..]
Receiving objects: 100% (75668/75668), 202.59 MiB | 6.19 MiB/s, done.
[..]
dev@vm:~$ du -hs linux
1,4G    linux

Using the tar-Archive instead:

dev@vm:~$ wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.11.1.tar.xz
[..]
linux-5.11.1.tar.xz 100%[===================>] 112,17M  9,14MB/s    in 13s     
[..]

So a https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-$gitver.tar.xz would be optimal ;)

Looks like the amdgpu patches are still not mainlined, so... enjoy this patched kernel I guess? Can't really follow why it is so hard to merge these commits to stable.

Hey fellow AMD users, this is just a PSA; Be sure to check this thread out: https://www.reddit.com/r/Amd/comments/lnmet0/an_update_on_usb_connectivity_with_500_series/

As it turns out, I myself was/is also affected by those problems. But mostly the 'replug' happens so fast I don't even notice it. But my kernel log sure does! :

Feb 23 09:45:21 eggzpc kernel: usbcore: registered new interface driver usbfs
Feb 23 09:45:21 eggzpc kernel: usbcore: registered new interface driver hub
Feb 23 09:45:21 eggzpc kernel: usbcore: registered new device driver usb
Feb 23 09:45:21 eggzpc kernel: usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
Feb 23 09:45:21 eggzpc kernel: usb usb4: We don't know the algorithms for LPM for this host, disabling LPM.
Feb 23 09:45:21 eggzpc kernel: usb: port power management may be unreliable
Feb 23 09:45:21 eggzpc kernel: usb usb6: We don't know the algorithms for LPM for this host, disabling LPM.
Feb 23 09:45:21 eggzpc kernel: usb usb8: We don't know the algorithms for LPM for this host, disabling LPM.
Feb 23 09:45:21 eggzpc kernel: usb 1-3: new full-speed USB device number 2 using xhci_hcd
Feb 23 09:45:21 eggzpc kernel: usb 5-1: new full-speed USB device number 2 using xhci_hcd
Feb 23 09:45:21 eggzpc kernel: usb 3-4: new full-speed USB device number 2 using xhci_hcd
Feb 23 09:45:21 eggzpc kernel: usb 7-2: new full-speed USB device number 2 using xhci_hcd
Feb 23 09:45:21 eggzpc kernel: usb 3-4: config 1 has an invalid interface number: 2 but max is 1
Feb 23 09:45:21 eggzpc kernel: usb 3-4: config 1 has no interface number 1
Feb 23 09:45:21 eggzpc kernel: usb 5-1: not running at top speed; connect to a high speed hub
Feb 23 09:45:21 eggzpc kernel: usbcore: registered new interface driver usbhid

Lets hope AMD adresses them soon!