Moved my nvme with manjaro (linux65) from Intel Gen11 to AMD r5 with updated BIOS and seem to be having few temporary issues, if at all
The flashing itself was weird however, at first it would fail on 2nd PD, but went good after I have moved power to a USB port. It kept rebooting into the flasher, however, even once all 4 were done. I think I have solved that by interrupting boot once.
Only 512MB of memory were reserved for the GPU. The GPU has access to use a large chunk of the memory beyond that if it needs to. If you are experiencing less issues with a larger allocation to the GPU, then maybe the UMA is bugged?
Entirely possible, because I haven’t had the same display issues (where a large chunk of the screen would either turn white or be flashing white) after changing to UMA_GAME_OPTIMIZED.
I did have one GPU-related hang/crash last Friday, where I had to force-reboot my laptop, though, with repeating messages like the one below:
Nov 10 10:35:29 saikrishna-Framework kernel: [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=14
Nov 10 10:35:29 saikrishna-Framework kernel: [drm:amdgpu_mes_reg_write_reg_wait [amdgpu]] *ERROR* failed to reg_write_reg_wait
There are definitely issues with Memory management and scatter gather (coalescing random GPU VRAM from system memory) even persisting into the current set of amdgpu patches in 6.7 mainline. Allocating 4GB Reserved region which doesn’t get touched by the rest of the kernel for general purpose alleviates this but doesn’t make it go away. So disabling SG is the best option at the moment.
ac_rtld error(1): too much LDS (used = 47360, max = 32768)
│ LLVM failed to upload shader
│ EE ../src/gallium/drivers/radeonsi/si_state_shaders.cpp:2557 si_build_shader_variant - Failed to build shader variant (type=3)
I am not sure if we are talking about the same issue. My issue is completely gone after updating mesa.
Hi all, got my Batch 3 a couple of weeks ago and asibe from a bum stick of RAM, everything works well EXCEPT OpenCL with darktable. I am running an Arch based distro (Arcolinux) and I have no general OS issues. But, the AMD driver packages (aur/opencl-amd) that I would normally install to enable OpenCL in darktable installs without issues but causes darktable to lock up. As darktable is my primary photo software I kinda need to get this working. I can muscle through it in CPU mode but OpenCL greatly accelerates the process.
I’m having the same or a very similar problem. For me, darktable runs fine, even with OpenCL enabled, but upon closing the program never fully exists but leaves behind a zombie process that also keeps the database locked.
Actually, I just tried the much newer rocm-opencl-runtime and it runs correctly with darktable (no zombie process that I can detect) but, if you use a simple-text-shadow watermark, it draws a black box behind the watermark instead of the drop shadow. simple-text watermarks behave normally with OpenCL. I have posted this (with sample images) on pixls.us.
Is there an official way to be alerted of updates?
When new Ubuntu kernel updates are available for the laptop, I have to manually check every so often and update, I would expect framework to have some thread about Linux distro fixes and bios updates together?
Just received my Ryzen 7840U system but having trouble getting to Step 9 of the guide. Installation completed successfully but after rebooting (which takes a LONG time) I can generally get to the login screen (though sometimes stuck on a black screen with _ for a bit) and move the mouse slightly or input a few chars of the password but then the system locks up and either stays locked or the screen blanks for a bit and goes back the locked login view.
Ubuntu is 22.04 (image from today), BIOS is JFP30.03.02, basically followed the installation guide verbatim other than selecting Minimal instead of Normal. Not really sure what to investigate next as everything seems as up to date as possible.
EDIT: I should also note that holding the power button for a “few” seconds turns off the screen but LED stays on. Holding it longer turns off the LED.
Is there any effort on upstreaming the OEM kernel specific parts that allows the framework 13th AMD to work properly ? Or is that kernel specifically chosen because it has been quality tested ? I’m just wondering for future kernel updates as well as other distros despite the fact that there is no official support for other distros than Ubuntu and Fedora as far as I’m aware.