-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AMD Ryzen 7 5800U support #155
Comments
You need a newer version of |
Ok. Thanks. Switched to 13.1-RC1 (RC2 now) and installed drm-devel-kmod from ports. Works pretty well. Although there is no GPU accelerated video. The only thing i have changed in /boot/loader.conf is I also get this line in the logs:
Can I fix it somehow? |
Xorg 1.20.14 still does not work on Cezenne CPUs, it crashes while, presumably, accessing AMDGPU. Also GPU offloading to NVIDIA does not work, I fail to make it detect more than one providers. Using FreeBSD 13.1-RC1, drm-devel-kmod 5.7.19.g20220223, NVIDIA driver 510.60.02. [drm] initializing kernel modesetting (RENOIR 0x1002:0x1638 0x17AA:0x3A5D 0xC6). |
Updated to FreeBSD 13.1-RC5. And added a second monitor via DP. I experience reboots on the DP monitor start.
Some of dmesg hope it helps:
|
I have a 5850u (which is the same cpu, just the 'pro' version) and it is working nicely (with gpu acceleration) on 14.0-CURRENT from April 7th 2022 along with drm-devel-kmod. This morning I tried 13.1-RC5 and drm-510-kmod, which unfortunately do not work. I am able to 'kldload amdgpu' which compared to the same command on the aforementioned working setup, but doesn't seem to load the module properly -- when I load the module on 14.0-CURRENT, I see a decent amount of information output. On 13.1-RC5 I see the following info output:
And when running 'startx' afterwards, the xorg server does not start. edit: I have also observed the xf86-video-amdgpu 2d driver providing a significantly smoother experience than the modesetting driver that is part of xorg-server. edit2: I was able to build drm-devel-kmod port on 13.1-RC5 and the 'amdgpu' module loads correctly. However I have now found that I am unable to move the mouse cursor (key input still works). I'm assuming this is i2c related and specific to my thinkpad x13 gen 2 (it works in 14.0-CURRENT). edit3: drm-54-kmod does not work on 13.1-RC5 either. tldr; the moral of this is:
|
so I done some digging and found the following missing pieces:
I will test this out and report back. |
Try to build recently created 5.10-lts branch from sources. It includes upstream support for all these Renoir chips. |
I will try that @wulf7 thanks for the advice |
Hi all. I have just tried 5.10-lts, it does not load on Cezanne CPU at all, reports 'amdgpu/green_sardine_sdma.bin' is missing, see my dmesg output below. So, 5.7-stable branch is the only that loads but still does not work - Xorg crashes at AMDGPU access. I have been investigating this issue for quite some time and came to conclusion that the problem is not in DRM driver, neither in Xorg, but in /lib/libthr.so.3 or even in /lib/libc.so.7 library which comes with FreeBSD/LLVM. In other words it is a bug in FreeBSD. drmn1: on vgapci1 |
Yes, even with the green sardine firmware missing the driver should still work (to a certain extent) with the renoir firmware as it had been doing so with the 5.7 branch. I had last tested 5.7 branch with 14.0-CURRENT with the April 6th release of install media. So if it is broken in FreeBSD as you say, the change has happened somewhere in that time. I did have the same outcome as you re: 5.10-lts branch though. |
Can you please show me your Xorg.0.log as well as /etc/X11/xorg.conf ? Thanks. I have installed missing green_sardine firmware manually from /usr/ports/graphics/gpu-firmware-kmod/ (strangely it's just missing in Makefile), now 5.10-lts driver loads ok, modesetting works, yet same issue with Xorg using amdgpu. |
I can try that tonight. If you don't mind, can you please provide the changes that you made? I was looking at adding the firmware files to gpu-firmware-amd-kmod which doesn't look too difficult. But if we're debugging this and trying to come to the same outcome, I would prefer we follow the same steps. |
I did not do any changes. I just installed missing firmware from their resting directories:
|
I wasn't able to replicate an install of green_sardine_* firmware files with this method, sorry. While I have some experience with the amdgpu driver, my experience with drm-kmod + gpu-firmware-kmod is limited :-) I would imagine that xf86-video-amdgpu being stuck at version 19.x is the reason behind the crashing that you are experiencing. |
Hi there! Can anybody add a pull request to https://github.com/freebsd/drm-kmod-firmware to restore green_sardine support? I opened an issue freebsd/drm-kmod-firmware#21 for that. |
I have done so. As mentioned in my PR, the next piece to be added is the relevant bits in the Makefile for the gpu-firmware-kmod port. |
As I said I begin thinking that the problem is not in Xorg/xf86-video-amdgpu per se, but in libc library used in FreeBSD 13. I would like to see if this same issue persists in FreeBSD 14-CURRENT. Can you please send me your Xorg.0.log for investigation ? |
Ok now I see what you're talking about. I tried out the 14.0-CURRENT image from April 14th 2022 and now I experience the same problem, even with v5.7 in use. So the breakage occured somewhere between April 7th and April 14th. With regards to xorg.conf - I don't change any defaults. The only 'tweaks' I make is to /usr/local/share/X11/xorg.conf.d/10-amdgpu.conf where I enable TearFree for no screen tearing. |
The firmware is available now. Updated to 13.1-RELEASE, installed gpu-firmware-amd-kmod-green-sardine and drm-510-kmod. No luck. Described the issue here #167 Can anybody test it also? |
Closing this issue, #167 will track the problem now that we (should) have everything to support this GPU generation. |
If *any* object of a certain WW mutex class is locked, lockdep will consider *all* mutexes of that class as locked. Also the lock allocation tracking code will apparently register only the address of the first mutex of a given class locked in a sequence. This has the odd consequence that if that first mutex is unlocked while other mutexes of the same class remain locked and then its memory then freed, the lock alloc tracking code will incorrectly assume that memory is freed with a held lock in there. For now, work around that for drm_exec by releasing the first grabbed object lock last. v2: - Fix a typo (Danilo Krummrich) - Reword the commit message a bit. - Add a Fixes: tag Related lock alloc tracking warning: [ 322.660067] ========================= [ 322.660070] WARNING: held lock freed! [ 322.660074] 6.5.0-rc7+ freebsd#155 Tainted: G U N [ 322.660078] ------------------------- [ 322.660081] kunit_try_catch/4981 is freeing memory ffff888112adc000-ffff888112adc3ff, with a lock still held there! [ 322.660089] ffff888112adc1a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: drm_exec_lock_obj+0x11a/0x600 [drm_exec] [ 322.660104] 2 locks held by kunit_try_catch/4981: [ 322.660108] #0: ffffc9000343fe18 (reservation_ww_class_acquire){+.+.}-{0:0}, at: test_early_put+0x22f/0x490 [drm_exec_test] [ 322.660123] freebsd#1: ffff888112adc1a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: drm_exec_lock_obj+0x11a/0x600 [drm_exec] [ 322.660135] stack backtrace: [ 322.660139] CPU: 7 PID: 4981 Comm: kunit_try_catch Tainted: G U N 6.5.0-rc7+ freebsd#155 [ 322.660146] Hardware name: ASUS System Product Name/PRIME B560M-A AC, BIOS 0403 01/26/2021 [ 322.660152] Call Trace: [ 322.660155] <TASK> [ 322.660158] dump_stack_lvl+0x57/0x90 [ 322.660164] debug_check_no_locks_freed+0x20b/0x2b0 [ 322.660172] slab_free_freelist_hook+0xa1/0x160 [ 322.660179] ? drm_exec_unlock_all+0x168/0x2a0 [drm_exec] [ 322.660186] __kmem_cache_free+0xb2/0x290 [ 322.660192] drm_exec_unlock_all+0x168/0x2a0 [drm_exec] [ 322.660200] drm_exec_fini+0xf/0x1c0 [drm_exec] [ 322.660206] test_early_put+0x289/0x490 [drm_exec_test] [ 322.660215] ? __pfx_test_early_put+0x10/0x10 [drm_exec_test] [ 322.660222] ? __kasan_check_byte+0xf/0x40 [ 322.660227] ? __ksize+0x63/0x140 [ 322.660233] ? drmm_add_final_kfree+0x3e/0xa0 [drm] [ 322.660289] ? _raw_spin_unlock_irqrestore+0x30/0x60 [ 322.660294] ? lockdep_hardirqs_on+0x7d/0x100 [ 322.660301] ? __pfx_kunit_try_run_case+0x10/0x10 [kunit] [ 322.660310] ? __pfx_kunit_generic_run_threadfn_adapter+0x10/0x10 [kunit] [ 322.660319] kunit_generic_run_threadfn_adapter+0x4a/0x90 [kunit] [ 322.660328] kthread+0x2e7/0x3c0 [ 322.660334] ? __pfx_kthread+0x10/0x10 [ 322.660339] ret_from_fork+0x2d/0x70 [ 322.660345] ? __pfx_kthread+0x10/0x10 [ 322.660349] ret_from_fork_asm+0x1b/0x30 [ 322.660358] </TASK> [ 322.660818] ok 8 test_early_put Cc: Christian König <christian.koenig@amd.com> Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Danilo Krummrich <dakr@redhat.com> Cc: dri-devel@lists.freedesktop.org Fixes: 09593216bff1 ("drm: execution context for GEM buffers v7") Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Danilo Krummrich <dakr@redhat.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230906095039.3320-4-thomas.hellstrom@linux.intel.com
If *any* object of a certain WW mutex class is locked, lockdep will consider *all* mutexes of that class as locked. Also the lock allocation tracking code will apparently register only the address of the first mutex of a given class locked in a sequence. This has the odd consequence that if that first mutex is unlocked while other mutexes of the same class remain locked and then its memory then freed, the lock alloc tracking code will incorrectly assume that memory is freed with a held lock in there. For now, work around that for drm_exec by releasing the first grabbed object lock last. v2: - Fix a typo (Danilo Krummrich) - Reword the commit message a bit. - Add a Fixes: tag Related lock alloc tracking warning: [ 322.660067] ========================= [ 322.660070] WARNING: held lock freed! [ 322.660074] 6.5.0-rc7+ freebsd#155 Tainted: G U N [ 322.660078] ------------------------- [ 322.660081] kunit_try_catch/4981 is freeing memory ffff888112adc000-ffff888112adc3ff, with a lock still held there! [ 322.660089] ffff888112adc1a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: drm_exec_lock_obj+0x11a/0x600 [drm_exec] [ 322.660104] 2 locks held by kunit_try_catch/4981: [ 322.660108] #0: ffffc9000343fe18 (reservation_ww_class_acquire){+.+.}-{0:0}, at: test_early_put+0x22f/0x490 [drm_exec_test] [ 322.660123] freebsd#1: ffff888112adc1a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: drm_exec_lock_obj+0x11a/0x600 [drm_exec] [ 322.660135] stack backtrace: [ 322.660139] CPU: 7 PID: 4981 Comm: kunit_try_catch Tainted: G U N 6.5.0-rc7+ freebsd#155 [ 322.660146] Hardware name: ASUS System Product Name/PRIME B560M-A AC, BIOS 0403 01/26/2021 [ 322.660152] Call Trace: [ 322.660155] <TASK> [ 322.660158] dump_stack_lvl+0x57/0x90 [ 322.660164] debug_check_no_locks_freed+0x20b/0x2b0 [ 322.660172] slab_free_freelist_hook+0xa1/0x160 [ 322.660179] ? drm_exec_unlock_all+0x168/0x2a0 [drm_exec] [ 322.660186] __kmem_cache_free+0xb2/0x290 [ 322.660192] drm_exec_unlock_all+0x168/0x2a0 [drm_exec] [ 322.660200] drm_exec_fini+0xf/0x1c0 [drm_exec] [ 322.660206] test_early_put+0x289/0x490 [drm_exec_test] [ 322.660215] ? __pfx_test_early_put+0x10/0x10 [drm_exec_test] [ 322.660222] ? __kasan_check_byte+0xf/0x40 [ 322.660227] ? __ksize+0x63/0x140 [ 322.660233] ? drmm_add_final_kfree+0x3e/0xa0 [drm] [ 322.660289] ? _raw_spin_unlock_irqrestore+0x30/0x60 [ 322.660294] ? lockdep_hardirqs_on+0x7d/0x100 [ 322.660301] ? __pfx_kunit_try_run_case+0x10/0x10 [kunit] [ 322.660310] ? __pfx_kunit_generic_run_threadfn_adapter+0x10/0x10 [kunit] [ 322.660319] kunit_generic_run_threadfn_adapter+0x4a/0x90 [kunit] [ 322.660328] kthread+0x2e7/0x3c0 [ 322.660334] ? __pfx_kthread+0x10/0x10 [ 322.660339] ret_from_fork+0x2d/0x70 [ 322.660345] ? __pfx_kthread+0x10/0x10 [ 322.660349] ret_from_fork_asm+0x1b/0x30 [ 322.660358] </TASK> [ 322.660818] ok 8 test_early_put Cc: Christian König <christian.koenig@amd.com> Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Danilo Krummrich <dakr@redhat.com> Cc: dri-devel@lists.freedesktop.org Fixes: 09593216bff1 ("drm: execution context for GEM buffers v7") Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Danilo Krummrich <dakr@redhat.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230906095039.3320-4-thomas.hellstrom@linux.intel.com
If *any* object of a certain WW mutex class is locked, lockdep will consider *all* mutexes of that class as locked. Also the lock allocation tracking code will apparently register only the address of the first mutex of a given class locked in a sequence. This has the odd consequence that if that first mutex is unlocked while other mutexes of the same class remain locked and then its memory then freed, the lock alloc tracking code will incorrectly assume that memory is freed with a held lock in there. For now, work around that for drm_exec by releasing the first grabbed object lock last. v2: - Fix a typo (Danilo Krummrich) - Reword the commit message a bit. - Add a Fixes: tag Related lock alloc tracking warning: [ 322.660067] ========================= [ 322.660070] WARNING: held lock freed! [ 322.660074] 6.5.0-rc7+ freebsd#155 Tainted: G U N [ 322.660078] ------------------------- [ 322.660081] kunit_try_catch/4981 is freeing memory ffff888112adc000-ffff888112adc3ff, with a lock still held there! [ 322.660089] ffff888112adc1a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: drm_exec_lock_obj+0x11a/0x600 [drm_exec] [ 322.660104] 2 locks held by kunit_try_catch/4981: [ 322.660108] #0: ffffc9000343fe18 (reservation_ww_class_acquire){+.+.}-{0:0}, at: test_early_put+0x22f/0x490 [drm_exec_test] [ 322.660123] freebsd#1: ffff888112adc1a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: drm_exec_lock_obj+0x11a/0x600 [drm_exec] [ 322.660135] stack backtrace: [ 322.660139] CPU: 7 PID: 4981 Comm: kunit_try_catch Tainted: G U N 6.5.0-rc7+ freebsd#155 [ 322.660146] Hardware name: ASUS System Product Name/PRIME B560M-A AC, BIOS 0403 01/26/2021 [ 322.660152] Call Trace: [ 322.660155] <TASK> [ 322.660158] dump_stack_lvl+0x57/0x90 [ 322.660164] debug_check_no_locks_freed+0x20b/0x2b0 [ 322.660172] slab_free_freelist_hook+0xa1/0x160 [ 322.660179] ? drm_exec_unlock_all+0x168/0x2a0 [drm_exec] [ 322.660186] __kmem_cache_free+0xb2/0x290 [ 322.660192] drm_exec_unlock_all+0x168/0x2a0 [drm_exec] [ 322.660200] drm_exec_fini+0xf/0x1c0 [drm_exec] [ 322.660206] test_early_put+0x289/0x490 [drm_exec_test] [ 322.660215] ? __pfx_test_early_put+0x10/0x10 [drm_exec_test] [ 322.660222] ? __kasan_check_byte+0xf/0x40 [ 322.660227] ? __ksize+0x63/0x140 [ 322.660233] ? drmm_add_final_kfree+0x3e/0xa0 [drm] [ 322.660289] ? _raw_spin_unlock_irqrestore+0x30/0x60 [ 322.660294] ? lockdep_hardirqs_on+0x7d/0x100 [ 322.660301] ? __pfx_kunit_try_run_case+0x10/0x10 [kunit] [ 322.660310] ? __pfx_kunit_generic_run_threadfn_adapter+0x10/0x10 [kunit] [ 322.660319] kunit_generic_run_threadfn_adapter+0x4a/0x90 [kunit] [ 322.660328] kthread+0x2e7/0x3c0 [ 322.660334] ? __pfx_kthread+0x10/0x10 [ 322.660339] ret_from_fork+0x2d/0x70 [ 322.660345] ? __pfx_kthread+0x10/0x10 [ 322.660349] ret_from_fork_asm+0x1b/0x30 [ 322.660358] </TASK> [ 322.660818] ok 8 test_early_put Cc: Christian König <christian.koenig@amd.com> Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Danilo Krummrich <dakr@redhat.com> Cc: dri-devel@lists.freedesktop.org Fixes: 09593216bff1 ("drm: execution context for GEM buffers v7") Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Danilo Krummrich <dakr@redhat.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230906095039.3320-4-thomas.hellstrom@linux.intel.com
Describe the bug
Hi there!
The new Ryzen 7 5800U doesn't work on 13.0-RELEASE with drm-fbsd13-kmod. Hope I will be fixed on 13.1-RELEASE.
Can help with testing and patching but don't want to upgrade the whole system.
FreeBSD version
PCI Info
pciconf -lv
DRM KMOD version
To Reproduce
Try to launch a wayland DM dwl:
Additional context
Found here a tread about the Cezanne core cpu. They say that drm-devel-kmod can be built on 13.1-BETA1, but Xorg 1.20.14 (also 1.20.13) crashes while accessing amdgpu.
The text was updated successfully, but these errors were encountered: