@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.
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) |
« First ‹ Previous 1 2 3 4 5 6 7 8 .. 10 Next › Last »
@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.
@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/
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...
@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?
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 :/
@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.
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?
@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.
@eggz Can you please share your /proc/cmdline, all of that magic amdgpu related params that help to avoid freezes/crashes?
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
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 :