Arch Linux User Repository

Hello! It seems that the "PINCTRL_AMD=y" Change in 5.19 solved all the raven incompatibilty problems (with mainline kernels). As far as I can see, the LTS kernel is no longer needed and we can go mainline again!

FYI: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc8&id=41ef3c1a6bb0fd4a3f81170dd17de3adbff80783

If you have newer AMD (CPU!) hardware, I welcome you to use my aur/linux-amd or aur/linux-amd-znver2 package

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.

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

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

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

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.

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: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a0e40018dcc3f59a10ca21d58f8ea8ceb1b035ac

So this decision was easy to take.

Thanks!!!

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:

https://www.spinics.net/lists/amd-gfx/msg47500.html

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

Many thanks again.

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)

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.

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.

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.

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

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.

Cheers.