Package Details: linux-amd-znver3 6.11.v.6-1

Git Clone URL: https://aur.archlinux.org/linux-amd-znver3.git (read-only, click to copy)
Package Base: linux-amd-znver3
Description: Linux kernel aimed at the znver3 AMD Ryzen CPU based hardware
Upstream URL: https://www.kernel.org/
Licenses: GPL2
Submitter: None
Maintainer: bebna
Last Packager: bebna
Votes: 12
Popularity: 0.30
First Submitted: 2023-05-04 15:47 (UTC)
Last Updated: 2024-11-03 03:09 (UTC)

Latest Comments

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

Anarconda commented on 2024-04-13 14:25 (UTC) 

With latest 6.8.6 kernel my UEFI shows: 'Error loading |vmlinuz-linux-amd-znver3: Unsupported' and returns to UEFI setup.

deneb commented on 2024-04-11 16:13 (UTC) (edited on 2024-04-11 16:19 (UTC) by deneb)

I have an ongoing issue with this package -- since it provides an initcpio preset file, any changes I make to it are moved to a .pacsave file and not restored on upgrade. (My specific case for editing the initcpio preset, by the way, is that I use UKIs to be picked up automatically by systemd-boot.)

I checked documentation, and kernel packages actually should not provide their own initcpio preset. Instead, these are generated/restored by /usr/share/libalpm/hooks/90-mkinitcpio-install.hook, and removed/backed up by 60-mkinitcpio-remove.hook.

What happens on upgrade is this:

  1. 60-mkinitcpio-remove.hook moves the modified linux-amd-znver3.preset to linux-amd-znver3.preset.pacsave

  2. the package installs its own linux-amd-znver3.preset

  3. 90-mkinitcpio-install.hook sees that linux-amd-znver3.preset already exists and forgoes overwriting it with linux-amd-znver3.preset.pacsave.

So please, remove the .preset file from this package and related ones.

And of course, many thanks for your effort in providing these kernels and the binary repo!

hardfalcon commented on 2024-04-11 00:47 (UTC)

@eggz: You're welcome. The config option that likely triggers the bug is CONFIG_GCC_PLUGIN_STACKLEAK=y btw, and your kernel config does use that option.

<deleted-account> commented on 2024-04-10 21:03 (UTC)

@hardfalcon Ill have a look at your fix tomorrow when I have more energy, thank you for the fix and thread, that would indeed explain the complexity of this error!

@anarconda thanks again for the feedback

<deleted-account> commented on 2024-04-10 20:28 (UTC)

@anarconda I know you're trying to help -- but I'm afraid the EFI problem is too complex to figure out on this evening, so im releasing an interim build without the efi module until I know why the module is giving trouble. Something is not right and last time upstream had to revert an EFI commit aswel ; I am incredibly suspicious.

Anarconda commented on 2024-04-10 20:22 (UTC)

I'm just trying to help to debug this thing with a little good humor.

<deleted-account> commented on 2024-04-10 20:16 (UTC)

@anarconda not trying to convince you -- just trying to fix the kernel @hardfalcon a fixed build is coming up. I am done with the breaking changes in the EFI module. :-)

hardfalcon commented on 2024-04-10 20:07 (UTC) (edited on 2024-04-10 20:31 (UTC) by hardfalcon)

eggz: I have a suspicion that you're affected by the same bug that I stumbled across, though it is caused by another commit.

The same commit is also present in kernel 6.6.26 btw.

Here's a fix that worked for me (at least with the reduced kernel config that I used for bisecting).

For details, see this thread.

Anarconda commented on 2024-04-10 20:02 (UTC)

I have this in my /proc/config.gz right now (kernel 6.8.5)

CONFIG_EFI=y CONFIG_EFI_STUB=y CONFIG_EFI_HANDOVER_PROTOCOL=y ...

CONFIG_X86_MEM_ENCRYPT=y CONFIG_AMD_MEM_ENCRYPT=y CONFIG_NUMA=y

Sorry, but still not convinced.

<deleted-account> commented on 2024-04-10 19:54 (UTC)

It seems this is the commit that broke my kernels:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.8.y&id=7596a378a1aeead848b13bf442a4a678ce64cfce

if you enable CONFIG_EFI you will get into trouble. Probably because of the CONFIG_AMD_MEM_ENCRYPT dependency. This isnt the first time CONFIG_EFI got broken by upstream so I will probably leave it off on all the kernels even if they fix it afterwards (which they did last time, but only after a while). builds are coming up.

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