Package Details: linux-amd-raven 6.8.v.8-1

Git Clone URL: https://aur.archlinux.org/linux-amd-raven.git (read-only, click to copy)
Package Base: linux-amd-raven
Description: Linux kernel with working amdgpu for Raven Ridge hardware
Upstream URL: https://www.kernel.org/
Keywords: amd kernel linux raven ravenridge
Licenses: GPL2
Submitter: eggz
Maintainer: eggz
Last Packager: eggz
Votes: 11
Popularity: 0.021344
First Submitted: 2018-12-19 18:07 (UTC)
Last Updated: 2024-04-27 16:38 (UTC)

Pinned Comments

eggz commented on 2022-08-03 12:05 (UTC) (edited on 2022-08-03 12:08 (UTC) by eggz)

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

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 :

[linuxkernels]
Server = http://nhameh.ovh/$repo/$arch
SigLevel = Optional TrustAll

Latest Comments

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

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)

@eggz

amdgpu is here: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/amdgpu

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

Arch package for them would be: https://archlinux.org/packages/core/any/linux-firmware/

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)

@eggz

I am talking about:

amd_iommu=pt amdgpu.aspm=0 amdgpu.audio=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