Package Details: linux-amd-raven-headers 5.4.v.203-1

Git Clone URL: (read-only, click to copy)
Package Base: linux-amd-raven
Description: Linux kernel with working amdgpu for Raven Ridge hardware
Upstream URL:
Keywords: amd kernel linux raven ravenridge
Licenses: GPL2
Submitter: eggz
Maintainer: eggz
Last Packager: eggz
Votes: 10
Popularity: 0.000006
First Submitted: 2018-12-19 18:07 (UTC)
Last Updated: 2022-07-02 18:44 (UTC)

Pinned Comments

eggz commented on 2019-12-10 16:37 (UTC) (edited on 2019-12-10 16:37 (UTC) by eggz)

I have placed this kernel on the 5.4 kernel version with intend of staying there (since 5.4 is expected to be an LTS release)

If you have newer AMD (CPU!) hardware, I welcome you to use my aur/linux-amd package, but for raven ridge, this is the end of the line.

eggz commented on 2019-04-02 20:17 (UTC) (edited on 2020-02-18 12:07 (UTC) by eggz)

Tired of compiling? Use this binary repo instead! Add this at the end of /etc/pacman.conf :

Server =$repo/$arch
SigLevel = Optional TrustAll

Latest Comments

eggz commented on 2021-12-29 13:32 (UTC)

Nevermind, I started using aur/rtw88-dkms-git pkg with the newest kernel and the wifi works fine now. No idea why the in kernel driver stopped working, but it's a thing.

eggz commented on 2021-12-22 13:02 (UTC)

linux-amd-raven has realtek wifi problems with version 5.4.168. They changed something in the netcode but so far I have been unable to isolate the problem. Looks like they released an untested kernel.

I uploaded 168 so you guys can share me the horrible wifi results ....

eggz commented on 2021-09-16 16:43 (UTC)

whoops. Somehow my git didnt push it to aur. Naughty pipeline!!

s3rj1k commented on 2021-09-16 14:43 (UTC)

@eggz latest change broke build at sha256sums check for renamed patch

eggz commented on 2021-07-15 05:54 (UTC)

@s3rj1k Good to know!

s3rj1k commented on 2021-07-14 21:24 (UTC)

@eggz amdgpu.ppfeaturemask=0xfff93fff works for me, no 5 minute freezes

eggz commented on 2021-07-14 20:43 (UTC)


As I said, I rarely have issues, it only had a crash every week or 2 on one laptop. I can't help you debug with a infrequent error like that.

s3rj1k commented on 2021-07-14 18:47 (UTC)

@eggz Can you please check on your laptop that has issues related to amdgpu drivers, does adding amdgpu.ppfeaturemask=0xfff93fff to kernel boot params help?


s3rj1k commented on 2021-07-13 18:49 (UTC)

@eggz yep, can confirm that to actually mitigate this issue one would need to match kernel version with exact firmware version. (probably kernel patch revision also matters)

Still no silver bullet, for me :(

Hoping here that 5.14 will fix this all of that BS, as per

eggz commented on 2021-07-13 17:55 (UTC)


If that's true that is a nice catch. I wouldn't have expected that. Let me know the results.

s3rj1k commented on 2021-07-13 16:55 (UTC)

so assuming this sudo pacman -U in pair with older kernels (like 5.4, 5.10) should fix issue, going to test that

s3rj1k commented on 2021-07-13 15:58 (UTC)

@eggz checkout this out, they pretty much confirm that issue is indeed caused by firmware, I am so angry right now, aggrrr

eggz commented on 2021-07-13 14:42 (UTC)

I understand, it is much appreciated. I might be low on time these days but not low on intrest. I didn't knew the firmware files of raven were updated, maybe to add more laptops and their oem implementations, very interesting. Thanks for pointing that out.

And yes you are right, bias is a factor here that clouds everything. Its very hard, if not impossible to find universal fixes by yourself.

s3rj1k commented on 2021-07-13 14:39 (UTC)

@eggz Just in case, I am not suggesting that you must do any research, I am only trying to disscuss possible options here, as seems that you have more then one raven based system.

I can only test on single laptop, so my tests are very biased.

s3rj1k commented on 2021-07-13 14:36 (UTC)


amdgpu is here:

take a look on raven*.bin commit log, they do update them, soo...

Arch package for them would be:

eggz commented on 2021-07-13 13:34 (UTC)

You are already confusing CPU microcode updates with general firmwareblob updates. The latter can indeed be used for accessing (in this case Vega) Gpu's, but its more of a "I can see the GPU" or "I cant see the GPU" situation.

The microcode for AMD is done by this package: amd-ucode

Sorry, unless I am mistaken;I do not think the answer lies there. Unless I'm wrong ofcourse. I'd love to be wrong and to learn something. But so far I have no indications the problem lies there. In any case, what is stopping you from downgrading the firmware package?

But I'm afraid that without some heavy kernel-amdgpu debugging and some C-Kernel development there won't be an easy fix available. And I personally have no time to take that work on my hands, especially without some hardware on-hands with that exact problem...

s3rj1k commented on 2021-07-13 13:25 (UTC)

@eggz Actually it all started a long time ago with newer linux-firmware image, makes me wonder, does this really an issue with kernel and not with firmware blob, as I can see this issue cross all kernel versions.

Do you have any ideas how can we track that firmware updates, I mean like, do they really update firmware code for ravenridge in there?

Do we really need latest updates?

If I remember correctly how it is done by Intel, they release CPU firmware updates only for recent CPUs and keep older code for older CPUs in their blobs.

Soo, maybe something went wrong with this AMD blobs approximately a year ago?

eggz commented on 2021-07-13 13:16 (UTC)

5 minutes, damn... I swear all these ravenridge laptops behave very diffrently :/

The only parameter I have ever used was amdgpu.noretry=0 , which enabled me to insta-recover from a certain crash.

Apart from that, I hope you find your fix :/

s3rj1k commented on 2021-07-13 13:12 (UTC)


I am talking about:

amd_iommu=pt amdgpu.aspm=0 amdgpu.bapm=0 amdgpu.deep_color=1 amdgpu.gpu_recovery=1 amdgpu.gttsize=8192 amdgpu.lockup_timeout=1000 amdgpu.noretry=0 amdgpu.ppfeaturemask=0xfffd3fff amdgpu.runpm=0 idle=nomwait iommu=pt ivrs_ioapic[32]=00:14.0 pcie_aspm=off processor.max_cstate=1 rcu_nocbs=0-7

It helps a bit, but still I have crash/freeze, few times a day.

Without them, can't work even 5 minutes.

Happens for me on every kernel.

I am trying to get some kind of working combination here, kernel + boot params.

eggz commented on 2021-07-13 12:43 (UTC)

AH you were wondering if I was using kernel cmdline parameters, I am not using anything at the moment.

I do have a crash/freeze on one of my raven systems yes, every week or so, maybe you are refering to that?

eggz commented on 2021-07-13 12:41 (UTC) (edited on 2021-07-13 12:41 (UTC) by eggz)

@s3rj1k I don't think the answer will be in there? It will show a BOOT_IMAGE and thats about it. I'm not sure what you are trying to get from me here.

I will not be able to tell you why a specified raven system has problems and others dont on 5.4, or 5.13 for that matter.

Exactly the same reason why my one ravenridge system works on 5.13 and the other does not, I don't really know. Its the exact snapshot of the AMDGPU module that works with the exact model/oem implementation of your hardware.

There will not be a simple oneliner command here that will give you all the answers, I also wish it was that easy. Rarely it might actually be, but mostly it isn't. Atleast not for me; I'm not really a kernel developer.

s3rj1k commented on 2021-07-13 12:32 (UTC)

@eggz Can you please share your /proc/cmdline, all of that magic amdgpu related params that help to avoid freezes/crashes?

eggz commented on 2021-07-13 12:12 (UTC) (edited on 2021-07-13 12:13 (UTC) by eggz)

All that code/patches targets amdgpu code not exactly present in 5.4. Backporting that to 5.4 requires knowledge of the AMDGPU module and C, both of which I do not (really) have.

In addition, a general notice: Modifying the stable 5.4 code with code added/modified after that might also introduce new problems on the raven hardware -- The exact reason why you stayed with linux 5.4

s3rj1k commented on 2021-07-13 11:49 (UTC)

@eggz Yea, I known about workarounds, I was talking about

eggz commented on 2021-07-13 11:43 (UTC)


What exact fix do you want me to backport? I have to specify here because I do not have the specific hardware or time to test something like this :(

Also, Did you take a look at


eggz commented on 2021-07-13 11:23 (UTC)

@s3rj1k "Seems that linux54 is the only stable kernel that has a working AMDGPU"

Well, by my experience that's a very dangerous thing to say, conveniently generalising hardware just doesn't work for AMDGPU. Even within the ravenridge hardware ranks there can be serious behaviour changes depending on the hardware but also on the implementation of the hardware on the baseboard by the OEM of your laptop. This can differ per model, so not only by OEM.

I have indeed one ravenridge laptop that only works on 5.4, while the other one perfectly works on 5.13. Both run stable on 5.4, though.

Having said that (just sharing my experiences), I will take a look at that fix, I will keep you posted.

s3rj1k commented on 2021-07-13 11:03 (UTC)

@eggz I am curious, is it possible to back-port a fix for that bug ?

Seems that linux54 is the only stable kernel that has a working AMDGPU, mostly no hard freezes on AMD Ryzen 7 2700U

eggz commented on 2021-06-29 13:38 (UTC)

Unfortunatly, 2 out of 3 systems stopped working (atleast their xorg did). The amdgpu module had severe problems with the display adapter. (3/4 startx commands fail to connect with the display adapter, freezing the system, requiring a reboot)

It seems that the first generation of ravenridge laptops will have problems with the newer upstream AMDGPU module, as I expected years ago. To provide ALL ravenridge hardware a compatible, working kernel, 5.4 seems like the best option.

(I will keep working around the gcc problems -- it should pose no problem)

eggz commented on 2021-06-29 12:20 (UTC)

@pooh and everyone else,

I got good news coming. Atleast it should be.

Since there are problems with the newer versions of GCC with the 5.4 kernel, I might aswell move this kernel up to a more recent rail.

So I might as well give in to popular demand: linux-amd-raven will follow upstream again.

5.13 is being tested on my systems as we speak.

So that means people like pooh should really stop using linux-raven-latest. Its a non public kernel specificly tailored for one of my systems. Or atleast run it at your own peril.

Pooh commented on 2021-06-29 06:54 (UTC)

i don't have a powersave available. warning! kernel linux-raven-latest from linuxkernels repo

CPU driver: acpi-cpufreq
Governors: performance schedutil
Frequencies: 2100000 1700000 1400000

eggz commented on 2021-06-29 06:49 (UTC)

What are you talking about?

Powersave is in the kernel. It's just not the default.


You can enable powersave with the cpupower package like this:

[eggz@eggzlen ~]$ sudo cpupower frequency-set -g powersave
[sudo] password for eggz: 
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3
Setting cpu: 4
Setting cpu: 5
Setting cpu: 6
Setting cpu: 7

The last command was run on a ravenridge laptop with this kernel.

Just run that command every boot and you will have powersaving enabled?

Pooh commented on 2021-06-29 06:43 (UTC) (edited on 2021-06-29 06:43 (UTC) by Pooh)

hi! could you enable powersave governor with the next linux-raven-latest update ? :)

Pooh commented on 2021-05-01 12:32 (UTC) (edited on 2021-05-01 12:36 (UTC) by Pooh)

Thanks! Consider replacing 5.4 with raven latest :)

P.S. Could you give a list of what you did with the linux kernel-raven-latest. It works fine for me!

eggz commented on 2021-05-01 11:21 (UTC)


It is done!

eggz commented on 2021-05-01 10:31 (UTC)

I will keep using 5.4 until Dec 2025,

After that I will see what the next longest LTS release will be :-)

Pooh commented on 2021-05-01 10:22 (UTC) (edited on 2021-05-01 10:25 (UTC) by Pooh)

You are not planning to upgrade this kernel to 5.10 LTS?

eggz commented on 2021-05-01 10:11 (UTC)

Ok, I'll get it done asap, but be warned, that kernel is not for public use, it is tailored for my athlon device. I did alot of tweaks and dropped alot of modules for that kernel.

I will do this fix since the HID was enabled before, even though my system doesnt need it, but if there are any more incompatibilities in the future there is a chance you are on your own!

Pooh commented on 2021-05-01 09:58 (UTC) (edited on 2021-05-01 09:59 (UTC) by Pooh)

I'm not talking about linux-amd-raven, but about linux-raven-latest from your repository (which is specified in the pinned comment)


eggz commented on 2021-05-01 09:34 (UTC)

What are you talking about? I think you are refering to changes that happened in 5.12/Mainline, but these are not introduced in 5.4/LTS, it still uses the non-split-up config, as you can see in your config:


Pooh commented on 2021-05-01 08:01 (UTC)

Please, Build linux-raven-latest with the latest changes from:


Scimmia commented on 2020-12-10 16:42 (UTC)

Please see the warning here:

eggz commented on 2020-10-31 22:37 (UTC)

Uhm, you're welcome, but the faster compression and decompression of the kernel's ramdisk has got nothing to do with your DE's memory leak.

This was just a general improvement..

bulio commented on 2020-10-31 22:21 (UTC)

Alright. I'll give it a try and then I'll report my results after a while. Thank you so much! <3

eggz commented on 2020-10-31 11:26 (UTC) (edited on 2020-10-31 11:37 (UTC) by eggz)

I have added 'COMPRESSION="lzop"' in the mkinitcpio preset of this kernel. I find this balanced compression for the ramdisk alot faster for installing, and booting from it. Please check your preset file in /etc/mkinitcpio.d/ to make sure that this change is adopted (as there is probably a pacsave file created there instead). Also make sure you have lzop installed.

bulio commented on 2020-10-26 18:35 (UTC)

I forgot to mention that kwin_x11 is usually the process that consumes a lot of RAM. I say usually since plasmashell is also another process that can take a lot of RAM for no apparent reason. It seems like disabling all of my eye candy in kwin makes no difference.

eggz commented on 2020-10-26 09:19 (UTC)


Thank you for the kind words. I am amazed that my kernel could trigger a memory leak somewhere on a specific DE. Though when that happens, shouldn't it be very easy to pinpoint where its coming from? you know, like $(ps aux|sort -n -k4| tail) or something?

bulio commented on 2020-10-26 09:09 (UTC)

Hi! I really love this kernel since it's the only one I can use without ever having a black screen after suspending my laptop and also it's the only one where TLP doesn't give me issues with my WiFi. However I have one issue with Plasma. It seems like after suspending my system, it starts consuming more and more RAM the more times I suspend it. It only happens when I boot with this kernel. It doesn't happen at all with the normal LTS or the stable one. It's such a weird thing so I have to reboot every couple of days or my system starts consuming 3.5GB+ of RAM without doing anything at all. I don't have this issue when I use i3-gaps. I think I should test other DEs to see if I have issues in those as well. Thank you so much for this kernel :)

eggz commented on 2020-10-20 08:35 (UTC)

@ejohn Thanks for your kind words! I'll try to keep it up. :-)

ejohn commented on 2020-10-20 04:00 (UTC)

Hello eggz, thank for all your work, I think the kernel is working really great in my setup. I installed it and ran a game and thought the performance improved.

Thanks and if I can help in anyway just ask.

eggz commented on 2020-07-31 09:32 (UTC)

Small update: I declared the linux.install file, it was a bit confusing it was not in the sources list (but it was in the git so the PKGBUILD could still use it) I also trimmed some more stuff.

take care, guys.

eggz commented on 2020-06-03 07:26 (UTC)

We temporarily have to moved our hosting from ovh to digitalocean. And judging by the way OVH support is treating us... Maybe even permanently.

Let me know if the (new) repo gives you any trouble.

eggz commented on 2020-06-02 14:11 (UTC)

Our hosting provider (OVH) is having some major difficulties: renewal of our service has been rejected and results in errors. Its out of our hands. Comment the repo in pacman.conf until OVH solves our problem ...

eggz commented on 2020-05-20 11:51 (UTC)

Still no structleak fix after the gcc10 release. 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. I hope they will still fix this for LTS, because I'm pretty sure the problem is not at my end...

eggz commented on 2020-05-15 15:27 (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.

eggz commented on 2020-05-15 07:01 (UTC)

gnulabis, thank you, I implemented the patch.

Why this upstream patch hasn't been implemented yet on the LTS is beyond me, its just sitting there in the mainline stable tree:

So this decision was easy to take.


gnulabis commented on 2020-05-14 20:15 (UTC)

Hi there, thank you for your work, I've built a new HTPC based on Ryzen 3400G and this kernel has solved all the issues I had with the stock one provided by Arch, in particular with suspend/resume cycles.

I've been seeing though many kernel WARNINGS like this in the system log during boot and also after a suspend/resume cycle:

WARNING: CPU: 3 PID: 243 at drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:1737 write_i2c_retimer_setting+0xca/0x3e0 [amdgpu]

Apparently, this only happens with external screens connected over HDMI.

Anyway, I found this patch and I tried it with your 5.4.v.41-1 and it seems to solve the issue for me:

Do you think it's something you could test and potentially merge?

Many thanks again.

eggz commented on 2020-05-14 20:07 (UTC)

I made gcc-10 builds possible by disabeling stack canaries. I will re enable them once the upstream guys figure it out (because I can't in short notice)

eggz commented on 2020-05-14 14:57 (UTC) (edited on 2020-05-14 14:57 (UTC) by eggz)

Hi Folks, I know some of you are yearning to use the first gcc10.1 build (as any true ZEN user should), but the build on 5.4 LTS looks anything but stable. I'm working as fast as I can to implement the right fixes to get gcc-10 built kernels in our hands, but I cant promise anything, especially on a derailed LTS version, But I'll try to implement them anyway.

If you HAVE to check it out and can't wait, the 'linux-next' and 'linux-new' (mainline) did build succesfully, you can take a look at them on our repo with those exact package names -- It appears that there are gcc10 fixed present upstream.

eggz commented on 2020-04-22 21:40 (UTC)

Most likely because I throw out all the intel and nvidia stuff in the config, but I cant pin it down. There are also rumors that this kernel is used, improved and made with unprecedented love and care, both from its users and the maintainer.

qpalz commented on 2020-04-22 21:14 (UTC) (edited on 2020-04-22 21:16 (UTC) by qpalz)

I am wondering how exactly is this kernel configured differently from linux-lts? I am trying to run ROCm / OpenCL 2 on my Ryzen 3400G. This kernel is the only kernel that works. I have tried using the default kernel, linux-lts, and also linux-lts with upstream module (ROCk), but none of these works. I just want to find out what is the magic that makes this kernel so special.

With other kernels, the GPU is still correctly detected. I can use Mesa to run OpenCL 1 programs, but I need OpenCL 2 which is only provided by ROCm.

eggz commented on 2020-04-21 08:23 (UTC)

Seems that the upstream code finally caught up, amdgpu fix no longer needed.

eggz commented on 2020-04-20 12:00 (UTC)

Right back at you: You are a terrific user.

I didn't spot the problem for some reason but I find it wonderful I can count on constructive feedback from users like you.


markuschaaf commented on 2020-04-20 11:39 (UTC)

That was fast! Reboot und shutdown are working again on my 2400g. (Still the occasional green screen after suspend, though.) You are a terrific maintainer!

eggz commented on 2020-04-19 21:24 (UTC)

The suggested patch is implemented. I would love some feedback on this one, because I do not encounter this bug on any of my AMD systems. If its any good, ill implement it on my linux-amd kernel aswell.

Thanks again Markuschaaf.

eggz commented on 2020-04-19 21:20 (UTC)

Markuschaaf, Good catch. I will implement it asap.

markuschaaf commented on 2020-04-19 18:54 (UTC)

Please apply until it's in upstream. This is a very annoying bug.

eggz commented on 2020-04-19 09:58 (UTC)

Ah yes, I had complaints about the suspend before. Didn't knew about the dri2 workaround though! I dont really use suspend myself.. But I probably wouldn't know where to look unless I'd spent way too much of time on it!

garfi commented on 2020-04-19 09:45 (UTC) (edited on 2020-04-19 09:45 (UTC) by garfi)

I placed the dri 2 option because I have a problem during a suspend-resume of the machine. During a summary the freeze screen and I no longer have access to the X server. With the dri 2 option I no longer have a problem but graphic degradation in 3D. It is the only solution that I found to have the possibility of making a suspended resume. It will therefore be more a problem of video drivers with the vega8 than a kernel problem.

eggz commented on 2020-04-18 08:26 (UTC) (edited on 2020-04-18 08:28 (UTC) by eggz)

For me, when I specify the option for dri2, it disables dri3 since it is the default. So that means when i specify dri3 or dont specify anything, it loads dri3.

I tested with other kernels with other versions and the result was the same. Here is the full disclosure:

Im a bit curious, why do you need dri2? dri3 is the new default now, as stated over here:

Extra info: I tested this with a dedicated VEGA64, but I guess the architecture for this test should be somewhat the same...

Honestly I dont think its the kernel since I did not modify amdgpu at all. It should have the same result as any kernel since amdgpu didnt change that much for vega even with the newer versioned kernels. For vega based hardware, nothing should have changed at all. Thats the sole reason I pinned this kernel on an LTS version.

garfi commented on 2020-04-17 22:11 (UTC)

@eggz thank you for your work and the repo that i use (amd-raven).

I am having a problem with my IGPU vega8 (ryzen3 2200G). I have to pass an option to X so that it uses dri 2.

I know it's probably a problem with video drivers, but do you think that another kernel could solve the problem?

vinceKahn commented on 2020-02-12 17:03 (UTC) (edited on 2020-02-12 17:37 (UTC) by vinceKahn)

Thank you!... after 3 days of troubleshooting terrible tearing when doing anything on any desktop (gnome, kde, xfce) I randomly came across a post this morning on a Manjaro forum referencing this package. I gave it a try and all my video issues went away. I have an AMD 3400G APU.

BTW all of the following kernel packages fail, only yours worked: Linux 5.5.3.arch1-1 Linux-lts 5.4.19-1 Linux-zen 5.5.3.zen1-1 Linux-amd 5.5.v.3-1

EDIT: Just tried your linux-amd 5.5 package and it appears to be working without issue. I must have tried the previous build, it looks like you just updated it yesterday.

Not sure what I'm going to do post this kernel?

eggz commented on 2020-01-29 18:48 (UTC)

@broken.pipe, Well normally it should still work, but guaranteeing the same quality would be impossible, I have seen newer kernels act really bad for older AMD GPU's in the past and thats the reason im splitting the package in a mainline and a LTS!

broken.pipe commented on 2020-01-28 11:54 (UTC)

thanks a lot for this package! My Ryzen 3400g works perfectly. I would like to upgrade to kernel 5.5 later, can I use your linux-amd kernel? are all patches included?

eggz commented on 2020-01-13 18:47 (UTC)

Ah yes, pinctrl_amd enables the problematic touchpad driver on some laptops (and admittedly also on my laptop, if you watch the git logs you could see that I spend some time searching for it ...) Problematic indeed, since it messes with some timings in order to "wake and allocate" the synaptics device at the right time. Sometimes the system needs a reboot if the timings were off by just a millisecond. Though I'd prefer to keep this driver since it still is a needed module for many AMD-only laptops, and thats also the point of this kernel ...

eggz commented on 2019-12-26 14:32 (UTC)

@librewish This kernel simply "cherry" picks (best effort, really..) all the right amd (Zenv1 and Vega) modules, but no special modules are really added.. (apart from the gentoo zenver1 optimisations git patch, but thats not about amdgpu..)

Maybe blocking out intel and nvidia modules can prove to provide a more "clean" environment? But that might just be wishful thinking on my part..

So Im afraid the best answer I can give you this kernel is made with more... love? <3

librewish commented on 2019-12-26 04:32 (UTC)

what is the exact config which enables amdgpu to behave correctly? i cant seem to figure out what is different with this kernel

eggz commented on 2019-12-10 16:37 (UTC) (edited on 2019-12-10 16:37 (UTC) by eggz)

I have placed this kernel on the 5.4 kernel version with intend of staying there (since 5.4 is expected to be an LTS release)

If you have newer AMD (CPU!) hardware, I welcome you to use my aur/linux-amd package, but for raven ridge, this is the end of the line.

eggz commented on 2019-11-27 22:56 (UTC)

@yochananmarqos there is none. I have seen numerous times where the gpg signature would be corrupted on random clients and they would be unable to update, I consider it wasted effort on both sides.

If you want to be really sure of the authenticity of this kernel you can always through the code (why take my word for it?) and compile it yourself via aur. I don't see how a gpg signature could change that since you shouldn't trust me just as much as the package.

yochananmarqos commented on 2019-11-27 03:05 (UTC)

@eggz: What's the GPG signature for the repo?

librewish commented on 2019-11-10 06:33 (UTC)

thank you with this there is no glitches and freezes on ryzen 5 3400g.

nnscr commented on 2019-10-17 15:01 (UTC)


I have an AMD Ryzen 7 2700U Pro (with Vega 10) CPU in my laptop (Thinkpad A485). Unfortunately my machine doesn't wake up after suspend with the latest kernel. The last kernel that I have tested that didn't had that problem was 5.0.5 with this configuration. Can someone point me into a direction on how to fix this?

My command line is as follows if relevant: loglevel=3 rd.udev.log-priority=3 vt.global_cursor_default=0 amdgpu.gpu_recovery=1 idle=nomwait


eggz commented on 2019-08-19 06:42 (UTC) (edited on 2019-08-30 07:37 (UTC) by eggz)

OK, I found the fix on for users with the Realtek RTL8822BE device:

-blacklist the broken new rt module:

/etc/modprobe.d/blacklist.conf: blacklist rtw88 blacklist rtwpci

-force the load of the old driver: /etc/modules-load.d/wifi.conf: rtl8822be

-install rtlwifi_new-extended-dkms from AUR (with your favorite AUR helper) pikaur -S rtlwifi_new-extended-dkms

optional: reinstall the kernel with the headers or just mkinitcpio -P

I hope this helps some people find the way to the bbs link for the fix.

eggz commented on 2019-08-07 09:36 (UTC)

Updated the kernelsources to 5.2 Mainline, since 5.1.21 has been marked EndOfLife at 2019-07-28

I also included the replacement of the RTLWIFI driver from staging, RTW88. However, I have one ravenridge laptop in my possesion where this new driver is not working (using a RTL8822BE device), as it is unable to scan for WIFI networks. If you have the same problem please use the old kernel ( until I figure out how to get this working (so far lots of tries, 0 succes).

This issue also appears on other 5.2 mainline based kernels -- also the vanilla arch one -- atleast on my laptop with the RTL8822BE device. Any info on this topic is welcome, since I wonder If my laptop is just a one-off or if it is a widespread issue.

eggz commented on 2019-08-07 09:36 (UTC)

Updated the kernelsources to 5.2 Mainline, since 5.1.21 has been marked EndOfLife at 2019-07-28

I also included the replacement of the RTLWIFI driver from staging, RTW88. However, I have one ravenridge laptop in my possesion where this new driver is not working (using a RTL8822BE device), as it is unable to scan for WIFI networks. If you have the same problem please use the old kernel ( until I figure out how to get this working (so far lots of tries, 0 succes).

This issue also appears on other 5.2 mainline based kernels -- also the vanilla arch one -- atleast on my laptop with the RTL8822BE device. Any info on this topic is welcome, since I wonder If my laptop is just a one-off or if it is a widespread issue.

eggz commented on 2019-06-20 08:50 (UTC)

Indeed, the problem has been fixed for quite a while now, but my kernel still contains some specific AMD kernelconfig options so I decided to keep maintaining this kernel none the less.

denzphee commented on 2019-06-20 08:37 (UTC)

Just wondering if this is still beneficial even if the stock kernel is working on my laptop that has a ryzen 5 2500u.

eggz commented on 2019-04-02 20:19 (UTC)

Updated the kernelsources to 5.1 Mainline, since 4.20.17 has been marked EndOfLife at 2019-03-19. Nobody wants an unpatched kernel.

eggz commented on 2019-04-02 20:17 (UTC) (edited on 2020-02-18 12:07 (UTC) by eggz)

Tired of compiling? Use this binary repo instead! Add this at the end of /etc/pacman.conf :

Server =$repo/$arch
SigLevel = Optional TrustAll