AMD Ryzen 7 5700G with Radeon Graphics does not work . #118
Comments
|
Fix release with the upstream commit (8bf0835132c19) is 5.12 but I guess we can backport this if this is the only needed thing. |
|
Looking it deeper, this patch is insufficient for this chip. |
|
I've got the 5700u- I'll try this tomorrow with the IDs changed for mine. |
|
Cloned from git, modified the file for the patch, recompiled, and installed. I also added the section to Now, it seems like it recognizes my card, but if I try
|
|
Interesting, are you on the current There was a recent FPU context issue for dcn1 but I thought dcn21 was confirmed working on 5.6. The |
|
Yeah- I got this after updating my FreeBSD CURRENT a few minutes prior. I had also cloned this git repo about an hour and a half prior. Edit: I can attach my modified file as well, to make sure I did it right. |
|
Hmm either we didn't actually make sure dcn21 doesn't have fpu context problems, or this FPU context error is somehow obscuring a real error (by hitting the cpu exception before the error reporting code runs) that would mean something from this hardware is not yet actually supported… Please try something like: diff --git i/drivers/gpu/drm/amd/display/dc/os_types.h w/drivers/gpu/drm/amd/display/dc/os_types.h
index c34eba1986..1eeff0bf3e 100644
--- i/drivers/gpu/drm/amd/display/dc/os_types.h
+++ w/drivers/gpu/drm/amd/display/dc/os_types.h
@@ -53,8 +53,8 @@
#if defined(CONFIG_DRM_AMD_DC_DCN)
#if defined(CONFIG_X86)
#include <asm/fpu/api.h>
-#define DC_FP_START() kernel_fpu_begin()
-#define DC_FP_END() kernel_fpu_end()
+#define DC_FP_START() { printf("+fpu %s (%s:%d)\n", __func__, __FILE__, __LINE__); kernel_fpu_begin(); }
+#define DC_FP_END() { printf("-fpu %s (%s:%d)\n", __func__, __FILE__, __LINE__); kernel_fpu_end(); }
#elif defined(CONFIG_PPC64)
#include <asm/switch_to.h>
#include <asm/cputable.h> |
|
@bluedudexoo Here's the upstream patch adding There are no similar changes for |
|
Fascinating! My C programming skills aren't the best, but I can dive in and learn a bit. Let me apply that debugging patch you suggested and check the results. |
|
Okay! Recompiled with the debug lines in there- this is the error. I'll eventually get a repo set up where I can just push the tar dumps to it lol.
|
|
Is this from the beginning of the It's very odd that there's a jump from 1141 back to 1197. It's like there's somehow interleaved (?!) multiple I'm not sure how this could happen but to be sure, try to manually |
|
I included the rest since it was technically an update (re-cloned from repo.) I have it loading in with Edit: another piece of the puzzle- possibly a solve? I used |
Oh that's fine (if it always loads, that is).
But do you actually have it working? I'd like to see a trace of where the second diff --git i/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c w/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
index 66f137397c..76fdfd9226 100644
--- i/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
+++ w/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
@@ -1198,6 +1198,7 @@ bool dcn21_validate_bandwidth(struct dc *dc, struct dc_state *context,
bool fast_validate)
{
bool voltage_supported;
+ printf("---%s\n", __func__); dump_stack();
DC_FP_START();
voltage_supported = dcn21_validate_bandwidth_fp(dc, context, fast_validate);
DC_FP_END(); |
|
No, unfortunately. If I specify the BusID in my Okay, let me get that up and running 😁 |
|
Okay! Appreciate your patience- got the repo up and running. This is my current textdump for the panic. |
|
I'm also not sure how much it helps, but it seems OpenBSD added support for this APU with their latest update. I know there's not much binary capability, but maybe I could help beta test some implementations? |
|
OHH. The interleaved call is because the system has already started a panic → vt postswitch → a new drm_atomic_commit for the terminal. Okay. I guess a real panic is obscured by the one coming from the fpu context reorder? Try reverting c937a405bdce2fd1 in base and rebuilding the kernel. (Funnily enough, it's a patch from me that ensures a panic is visible even when using a GUI, I didn't really expect that to happen… to be fair, we're testing unsupported hardware here.) OpenBSD's drm port is completely independent. Sadly we're behind now, they're at 5.10… |
|
Just so I understand, you mean the commit to the FreeBSD source? Or the drm-kmod source? And ahh, that's about what I figured. Oh well. 😁 Edit: figured it out! Building now. |
|
New dump here! |
|
Well that changed nothing. Let's just block that code path instead: diff --git i/drivers/gpu/drm/linux_fb.c w/drivers/gpu/drm/linux_fb.c
index 2cf264bf86..a311102252 100644
--- i/drivers/gpu/drm/linux_fb.c
+++ w/drivers/gpu/drm/linux_fb.c
@@ -127,7 +127,7 @@ vt_kms_postswitch(void *arg)
DRM_DEBUG("fb helper is null!\n");
return -1;
}
- drm_fb_helper_restore_fbdev_mode_unlocked(sc->fb_helper);
+ // drm_fb_helper_restore_fbdev_mode_unlocked(sc->fb_helper);
}
return (0);
} |
|
Looks like there are less fpu debugging messages? |
|
Hey guys, got a bit of a funfusing conundrum going on here. I've got an AMD 5600G box running 14-CURRENT, cloned the 5.7-wip repo, built it with the minor mod to amdgpu_drv.c as noted by OP. Everything built cleanly & kldload-ed without complaint, resulting in Renoir firmware being autoloaded. With |
Well, you've added the PCI ID ("minor mod to amdgpu_drv.c") so you've enough "support" :) Green Sardine is a very minor revision of Renoir, it's not that surprising that treating it the same as original Renoir "just works". Upstream 5.11 where support is properly added does also add a bunch of conditionals deep inside various things but evidently they're not necessary for it to work. |
|
Is main the same as 5.7? |
|
No. Main is 5.6.0 now |
|
Ah, I was wondering- 5.7 doesn't build. When was it updated? |
|
Last time it was updated 2 days ago. It requires recent CURRENT (clang 13) to be built |
|
I'll update and try again😊 |
|
FYI, a recent update to base src broke 5.7-wip, at least in my case. Haven't been able to get it to work again. However, surprise surprise, 5.6-stable (with modification to amdgpu_drv.c !) suddenly started working instead. I dug through the base src commits back to about ~8 days before 5.7-wip stopped working, but nothing in those commits appeared to have anything to do at all with drm-kmod. A buildworld & 5.6-stable for whatever reason jived. |
|
Hello, is there any chance for news on the issue in the near term? |
I guess they're taking a break or w/e |
0x1002, 0x164C card support was added to 5.7-stable branch in commit 5eb4816 as it appeared to be plain Renoir and was reported to work. If someone would get success with other PID/VIDs they would be added too. Otherwise, you should wait for 5.10 |
|
Please add: It is fully functional & I haven't been able to get it to break or crash for over 2 months now. |
They are reported to work[1]. [1] freebsd#118 (comment)
Included in to |
|
Thank you kindly. I'll keep testing. There may be a 5700G coming across my bench in the near future & will report back if anything curious pops up. Excellent work guys! |
They are reported to work[1]. [1] freebsd#118 (comment)
|
Is there any chance that it will work with FreeBSD 13? UPD: work fine with |
|
It does not work to me. I upgraded to FreeBSD 13.1 and was able to successfully build And the driver has this weird report in dmesg: |
|
@pointcheck probably you need to uninstall nvidia driver. |
|
Just have tried with nvidia.ko and nvidia-modeset.ko unloaded, pretty same effect! It looks more like an Xorg issue, it behaves (crashes) the same way with both AMD and nVidia cards/drivers. The only way I can run Xorg now is through |
|
I suspect that xorg may load back nvidia drivers, you can check it using |
|
It does not. It's rather a bug in Xorg. |
have you been able to solve this issue? |
What X server do you use on OpenBSD ? I was not able to solve this Xorg crash issue. I am currently using Xorg with modesetting driver. It works but there's no GL/EGL, it is slow and frustrating. Seems that Xorg is now completely abandoned (in favour of Wayland), no one wants to fix bugs in it any more. :-( I nearly in position to dive into Xorg codes my self. |
|
I should mention, that I have not a Ryzen 7 5700 CPU but a Ryzen 5 Pro 5650u (which is also Cezanne and also device ID 0x1638 )
just default install of OpenBSD 7.0, worked out of the box. |
|
What is the default one on OpenBSD 7.0 ? Sorry, I have never touched OpenBSD, have no clue how it's made. If that's Xorg, can you please show /var/log/Xorg.0.log ? |
|
I just installed OpenBSD and it worked out of the box with the version from the installer. If you want to dig into their code > https://cvsweb.openbsd.org/xenocara/ have fun |
|
Hmm.. it seems they are using Xorg 21.1.3 (Xorg adopted new versioning a year ago). Have to try it on FreeBSD. |
|
Should be ok with updated xf86-video-amdgpu |
|
drm-510 solve this. |
Describe the bug
AMD Ryzen 7 5700G with Radeon Graphics does not recognized with amdgpu.ko
FreeBSD version
FreeBSD akatsuki 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n249842-42dfad2ef12: Tue Oct 5 01:06:52 JST 2021 takawata@akatsuki:/usr/obj/usr/home/takawata/projects/freebsd/src/amd64.amd64/sys/CORONEL amd64
PCI Info
pciconf -lv
vgapci0@pci0:11:0:0: class=0x030000 rev=0xc8 hdr=0x00 vendor=0x1002 device=0x1638 subvendor=0x1043 subdevice=0x8809
vendor = 'Advanced Micro Devices, Inc. [AMD/ATI]'
device = 'Cezanne'
class = display
subclass = VGA
DRM KMOD version
5.6-wip
To Reproduce
Loading amdgpu.ko
Additional context
Adding
and
put /usr/local/etc/X11/xorg.conf.d/amdgpu.conf
will solve the problem.
This is a kind of backport from Linux .
The text was updated successfully, but these errors were encountered: