Package Details: linux-amd-znver2 6.5.v.5-1

Git Clone URL: https://aur.archlinux.org/linux-amd-znver2.git (read-only, click to copy)
Package Base: linux-amd-znver2
Description: Linux kernel aimed at the znver2 AMD Ryzen CPU based hardware
Upstream URL: https://www.kernel.org/
Licenses: GPL2
Submitter: eggz
Maintainer: eggz (NhaMeh)
Last Packager: eggz
Votes: 15
Popularity: 0.72
First Submitted: 2020-10-26 18:04 (UTC)
Last Updated: 2023-09-23 10:25 (UTC)

Pinned Comments

eggz commented on 2020-10-26 18:15 (UTC)

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

Latest Comments

1 2 3 4 5 6 .. 14 Next › Last »

eggz commented on 2023-08-26 16:34 (UTC) (edited on 2023-08-26 16:39 (UTC) by eggz)

Preliminary tests on the 6.5 RC point out that the AMD pstate in an active state is now supported on znver2. However, the parameter CONFIG_X86_AMD_PSTATE_DEFAULT_MODE=3, which is supposed to autoenable this driver, Does not work for znver2 cpus. (it does seem to work for higher archs)

So please make sure you keep passing the amd_pstate=active to your kernel to activate pstate on your znver2 CPU, despite of what you might have heared.

EDIT: to be clear: only pass amd_pstate=active on linux 6.5, on linux 6.4 it is amd_pstate=passive

1llum1n4t3d commented on 2023-08-19 23:48 (UTC)

Thanks for maintaining and keeping this package up2date!

Deneb commented on 2023-08-07 21:41 (UTC)

Understood! Appreciate the explanation, and the work you do.

eggz commented on 2023-08-07 20:48 (UTC)

@Deneb sorry but my build pipelines use cloned local git repositories to function and alot of functionality, flexibility (and possible error reproducing) depends on it. changing the pipelines to a tarball, while not impossible, would require enourmous effort and time from me I simply do not have to make it(building,installing,testing,reverting commits from upsteam,...) all work on my end too.

I personally prefer the git way, while I know its a larger pull from the internet -- that's why I put the gitrepo in the correct place localy before I do the makepkg so it doesnt have to download it all over again.

TL;DR ==> When upstream messes up that simple,fast and flat tarball becomes my enemy.

Deneb commented on 2023-08-07 20:40 (UTC) (edited on 2023-08-07 20:40 (UTC) by Deneb)

Okay, thanks :)

On another note - could the PKGBUILDs be changed to pull the kernel source tarballs instead of the full repository? Would save on disk space and time in the download phase.

eggz commented on 2023-08-07 20:35 (UTC)

@deneb Thank you for saying, I realised the same thing a while ago and I am on it :-)

Deneb commented on 2023-08-07 20:34 (UTC) (edited on 2023-08-07 20:35 (UTC) by Deneb)

My bad, I've just realised that this is the wrong AUR package.

The issue is still present for linux-amd and likely also linux-amd-znver3 (judging by the modification times).

eggz commented on 2023-08-07 20:02 (UTC)

@deneb

Not true, it has been updated last build:

[root@buildpc ~]# pacman -Q gcc
gcc 13.2.1-3


[2023-08-06T03:39:46+0000] [ALPM] upgraded gcc-libs (13.1.1-2 -> 13.2.1-3)

And the kernel was build on

 Sun Aug  6 03:53:53 UTC 2023

I'm going to assume you are using old info. That being said, I fixed the buildserver that it will always update before autobuild next time, this shouldn't happen again.

Deneb commented on 2023-08-07 19:37 (UTC)

DKMS modules still fail to build after clearing the package cache and reinstalling current gcc and linux-amd from the pinned linuxkernels repo.

Seems the build server is compiling with gcc 13.2.1-2, while the current version in the Arch Linux repositories is 13.2.1-3.

eggz commented on 2023-08-06 04:00 (UTC)

did a rebuild with latest updates, any luck?

1 2 3 4 5 6 .. 14 Next › Last »