Package Details: linux-amd 6.10.5-1

Git Clone URL: https://aur.archlinux.org/linux-amd.git (read-only, click to copy)
Package Base: linux-amd
Description: The Linux kernel and modules - With some improvement patches
Upstream URL: https://www.kernel.org/
Licenses: GPL-2.0-only
Provides: KSMBD-MODULE, VIRTUALBOX-GUEST-MODULES, WIREGUARD-MODULE
Replaces: virtualbox-guest-modules-arch, wireguard-arch
Submitter: None
Maintainer: None
Last Packager: archdevlab
Votes: 34
Popularity: 0.135686
First Submitted: 2019-11-10 15:20 (UTC)
Last Updated: 2024-08-21 00:22 (UTC)

Dependencies (31)

Required by (7)

Sources (21)

Pinned Comments

archdevlab commented on 2024-08-15 03:38 (UTC)

Hi

I have adopted this package and have updated it!

Thanks!

<deleted-account> commented on 2023-05-04 16:38 (UTC)

GCC13.1 is mainlined in arch, so this means znver4 support can kick off on this kernel. The graysky compile patches have been updated too.

This kernel now natively supports the znver4 arch, but this kernel will most likely keep working on all AMD ryzen hardware. It's better to be able to address certain small perks or issues per architecture now and in the future.

If you use znver3 based hardware, please use linux-amd-znver3
If you use znver2 based hardware, please use linux-amd-znver2
If you use raven based hardware, please use linux-amd-raven

<deleted-account> commented on 2020-10-26 18:15 (UTC)

GCC11.1 is mainlined in arch, so this means znver3 support can kick off on this kernel. The graysky compile patches have been updated too.

This kernel now natively supports the znver3 arch, but this kernel will most likely keep working on all AMD ryzen hardware. It's better to be able to address certain small perks or issues per architecture now and in the future.

If you use znver2 based hardware, please use linux-amd-znver2
If you use raven based hardware, please use linux-amd-raven

<deleted-account> commented on 2019-11-10 15:23 (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

« First ‹ Previous 1 .. 27 28 29 30 31 32 33 34 35 36 37 Next › Last »

<deleted-account> commented on 2020-05-21 09:09 (UTC)

OMG! We don't speak of shintel here... Just kidding, 'linux-test' coming right up.

usuariopolivalen commented on 2020-05-21 07:41 (UTC)

@eggz

I have mistaken the cpu of the user, it was Intel so the kernel stucks at boot. Can you make the same as before with bat 0,1,t... with other "vanilla" kernel without amd pacthes please? Just to test and report to Linux this problem. Thanks in advance!

usuariopolivalen commented on 2020-05-20 15:10 (UTC) (edited on 2020-05-20 15:32 (UTC) by usuariopolivalen)

@eggz I have send the repo to the user, let's see if it fix the problems. I feel like asus have a serious disorder in them laptops -.- i hope they fix it in the future and attend the problem of now in the shot-term future.

PD: other thing, what patch have you used?

<deleted-account> commented on 2020-05-20 14:45 (UTC)

Nevermind, I pushed it directly. Feel free to test when you have the time.

<deleted-account> commented on 2020-05-20 14:25 (UTC)

Well, looks like we have to do everything ourselves. That's okay, I'm already warmed up with the gcc-10 shenanigans. Do you have specific hardware to test this on? I will provide you a testbuild on the repo in a moment. I will do it for BAT0, BATT AND BAT1.

usuariopolivalen commented on 2020-05-20 14:18 (UTC)

The problem is that another Asus put the battery in bat1 nor the batt or bat0 so.. Please tell me your opinion

usuariopolivalen commented on 2020-05-20 14:17 (UTC)

@eggz do you remember when we spoke about Asus thresholds? If you can I would need you to recompile one of those kernels but with another patch. This patch have to containe the same as the before patch . Change batt or bat0 to bat1 or add another option to the patch . May be something like: / The WMI method does not provide a way to specific a battery, so we * just assume it is the first battery. + * Note: On some newer ASUS laptops (Zenbook UM431DA), the primary/first + * battery is named BATT. / - if (strcmp(battery->desc->name, "BAT0") != 0) + if (strcmp(battery->desc->name, "BAT0") != 0 && + strcmp(battery->desc->name, "BATT") != 0 && + if (strcmp(battery->desc->name, "BAT1") != 0 ) return -ENODEV;

if (device_create_file(&battery->dev,

<deleted-account> commented on 2020-05-20 11:49 (UTC)

Still no structleak fix. The kernelconfig gets overridden during the build where structleak is disabled. Since this exact problem does not occur in my upstream 5.7 builds, I'm pretty sure this is not really intended. but I'm afraid for mainline they will just wait till it hits 5.7, So I guess until then, no structleak.

<deleted-account> commented on 2020-05-15 15:00 (UTC)

I fixed basic stackprotection, but extra kernel hardening like structleak does not seem functional on 5.6 kernels. I will wait for upstream for that one.

<deleted-account> commented on 2020-05-15 10:38 (UTC)

I temporarily disabled stack canaries and used an upstream supression patch to get the gcc-10.1 builds going. I will re enable them as soon everything catches up. Have fun.

« First ‹ Previous 1 .. 27 28 29 30 31 32 33 34 35 36 37 Next › Last »