Package Details: linux-amd-znver3 6.12.v.5-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: 10
Popularity: 0.132612
First Submitted: 2023-05-04 15:47 (UTC)
Last Updated: 2024-12-15 16:04 (UTC)

Latest Comments

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

Gnatzelle commented on 2024-04-13 14:28 (UTC) (edited on 2024-04-13 14:31 (UTC) by Gnatzelle)

Same problem here like Anarconda... 6.8.4 is the last Kernel that boots normally. Using systemd-boot btw

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.

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