Package Details: linux-amd-znver2-headers 6.11.0-1

Git Clone URL: https://aur.archlinux.org/linux-amd-znver2.git (read-only, click to copy)
Package Base: linux-amd-znver2
Description: Headers and scripts for building modules for the linux-amd-znver2 package
Upstream URL: https://www.kernel.org/
Licenses: GPL-2.0-only
Submitter: None
Maintainer: archdevlab
Last Packager: archdevlab
Votes: 17
Popularity: 0.41
First Submitted: 2020-10-26 18:04 (UTC)
Last Updated: 2024-10-11 02:39 (UTC)

Required by (0)

Sources (6)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 .. 16 Next › Last »

old4ever commented on 2023-11-17 20:18 (UTC)

why don't you use archlinux kernel sources? pretty sure I don't know anything, but they have some patches for vanilla kernel and there's the config exclusively made for arch

<deleted-account> commented on 2023-08-26 16:34 (UTC)

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.

<deleted-account> 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.

<deleted-account> 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).

<deleted-account> 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.

« First ‹ Previous 1 2 3 4 5 6 7 8 .. 16 Next › Last »