|Summary:||reproducible crash with graphics/drm-fbsd13-kmod|
|Product:||Ports & Packages||Reporter:||George Michaelson <ggm>|
|Component:||Individual Port(s)||Assignee:||freebsd-x11 (Nobody) <x11>|
|Severity:||Affects Only Me||CC:||doctorwhoguy, grahamperrin, greg, manu, mizhka, teodorsigaev|
Description George Michaelson 2021-02-08 01:06:55 UTC
Created attachment 222251 [details] info file [root@oldie /var/log]# pkg info |egrep kmod\|video-ati\|video-intel drm-fbsd13-kmod-5.4.92.g20210202 DRM modules for the linuxkpi-based KMS components gpu-firmware-kmod-g20201213 Firmware modules for the linuxkpi-based KMS components xf86-video-ati-19.1.0_3,1 X.Org ati display driver xf86-video-intel-2.99.917.914,1 X.Org legacy driver for Intel integrated graphics chipsets [root@oldie /var/log]#
Comment 2 George Michaelson 2021-02-08 01:08:41 UTC
FreeBSD oldie 13.0-BETA1 FreeBSD 13.0-BETA1 #0 releng/13.0-n244471-638e531019f: Fri Feb 5 17:44:44 UTC 2021 firstname.lastname@example.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 https://bsd-hardware.info/?probe=bc83ef99fb
Comment 3 Emmanuel Vadot 2021-02-08 08:13:31 UTC
Could you try to either disable the AMD dGPU or not loading amdgpu.ko ? I also have a laptop with an AMD dGPU, I haven't tested it in a while but last time I made sure that we didn't panic when loading both module, maybe something changed or more is needed for your hardware. Also since we don't support dGPU for now (at least from my experience on my laptop) there no real reason for you to load amdgpu for now.
Comment 4 George Michaelson 2021-02-08 23:58:00 UTC
The problem occurs with either radeonkms.ko or amdgpu.ko loaded. I have tried both paths, and alternates for xf86-video, I only sent one stacktrace but I am confident the crash happens without amdgpu.ko loaded. If it is possible to "talk" to the card without some .ko loaded, I can try that as well. Modesetting configuration says "no screen found" so I suspect not.
Comment 5 Greg V 2021-02-09 12:04:04 UTC
Hmmmm this is the same Xorg process → linux_cdev_pager_populate → vm_page_busy_acquire code path as with Renoir@5.4 https://github.com/freebsd/drm-kmod/issues/36 but now on very old (Terascale/R600) hardware o_0 Would be funny if this one is also fixed by 5.5… Try installing the driver from source @ https://github.com/freebsd/drm-kmod/tree/5.5-wip ? (BTW, this hardware is radeonkms only, forget about amdgpu)
Comment 6 George Michaelson 2021-02-09 23:57:03 UTC
(In reply to Greg V from comment #5) git clone-d the drm-kmod, placed it into the work/ path for drm-fbsd13 removed the .install type files, make/make install. I did not enable the intel device in xorg.conf, solely the "radeon" driven card. This is the crash now: Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0xffffffff80bf3c54 stack pointer = 0x0:0xfffffe00d0ee1730 frame pointer = 0x0:0xfffffe00d0ee1730 code segment = base rx0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1207 (Xorg) trap number = 9 WARNING !drm_modeset_is_locked(&crtc->mutex) failed at /usr/ports/graphics/drm-fbsd13-kmod/work/drm-kmod-drm_v5.4.92_2/drivers/gpu/drm/drm_atomic_helper.c:621 #0 0xffffffff82a50683 at linux_dump_stack+0x23 #1 0xffffffff829cf3c3 at drm_atomic_helper_check_modeset+0xb3 #2 0xffffffff82ad899d at intel_atomic_check+0x8d #3 0xffffffff829ce360 at drm_atomic_check_only+0x400 #4 0xffffffff829ce793 at drm_atomic_commit+0x13 #5 0xffffffff829db3b8 at drm_client_modeset_commit_atomic+0x148 #6 0xffffffff829db119 at drm_client_modeset_commit_force+0x69 #7 0xffffffff82a1b42a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #8 0xffffffff82a153f7 at vt_kms_postswitch+0x167 #9 0xffffffff80a54d0b at vt_window_switch+0x12b #10 0xffffffff80a51e1f at vtterm_cngrab+0x4f #11 0xffffffff80b93866 at cngrab+0x16 #12 0xffffffff80bf8e4c at vpanic+0xec
Comment 7 Andriy Gapon 2021-02-10 07:24:34 UTC
(In reply to George Michaelson from comment #6) Note that the stack trace you pasted is not from the panic, it's from the warning. The real stack trace would be way down below after all the warning junk.
Comment 8 George Michaelson 2021-02-10 21:05:54 UTC
Sorry. I was stupid with the paste. I confirm amdgpu.ko is not live. WARN_ON(!mutex_is_locked(&fbc->lock))WARN_ON(!mutex_is_locked(&fbc->lock)) panic: general protection fault cpuid = 0 time = 1612878311 KDB: stack backtrace: #0 0xffffffff80c46315 at kdb_backtrace+0x65 #1 0xffffffff80bf8ee1 at vpanic+0x181 #2 0xffffffff80bf8d53 at panic+0x43 #3 0xffffffff8102d1a7 at trap_fatal+0x387 #4 0xffffffff8102c66e at trap+0x8e #5 0xffffffff81003d38 at calltrap+0x8 #6 0xffffffff80ee1207 at vm_page_busy_acquire+0x127 #7 0xffffffff82a7cb2e at ttm_bo_vm_fault+0x2ce #8 0xffffffff82c9043f at radeon_ttm_fault+0x4f #9 0xffffffff82a50c8b at linux_cdev_pager_populate+0x11b #10 0xffffffff80ecb0a2 at vm_fault_allocate+0x2a2 #11 0xffffffff80ec9dd6 at vm_fault+0x416 #12 0xffffffff80ec989d at vm_fault_trap+0x6d #13 0xffffffff8102d3a8 at trap_pfault+0x1f8 #14 0xffffffff8102c9dd at trap+0x3fd #15 0xffffffff81003d38 at calltrap+0x8 Uptime: 4m30s Dumping 489 out of 8064 MB:..4%..14%..23%..33%..43%..53%..63%..72%..82%..92%
Comment 9 email@example.com 2021-02-11 02:34:20 UTC
Interesting, I faced with the same problem with Renoir on my notebook and published the patch before I found this thread, sorry. Could somebodu have a look to my patch and/or try it? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253427
Comment 10 George Michaelson 2021-02-11 03:00:59 UTC
(In reply to firstname.lastname@example.org from comment #9) Tried that patch: still crashes.
Comment 11 email@example.com 2021-02-11 08:51:30 UTC
*** Bug 253427 has been marked as a duplicate of this bug. ***
Comment 12 firstname.lastname@example.org 2021-02-11 11:54:42 UTC
Just for information - I got a full success with Renoir (AMD Ryzen 7 PRO 4750U) with https://github.com/freebsd/drm-kmod/tree/5.5-wip branch (62591463e4dd5b0225278bd1911e7562ec9e063d) and http://sigaev.ru/misc/5.5-wip.patch patch. glxgears works. How to do: % cd /usr/ports/graphics/drm-fbsd13-kmod % make patch % rm -rf work/drm-kmod-drm_v5.4.92_2/* Clone pointed branch into work/drm-kmod-drm_v5.4.92_2/ and apply patch, then make all deinstall install and reboot. Hope, it will be useful until ports version will work correctly. If somebody has a better idea I hope to have a bit of time to test idea.
Comment 13 Graham Perrin 2021-02-15 00:49:16 UTC
Do the panics occur immediately at load time? Or later, maybe during automated start of a login manager?
Comment 14 email@example.com 2021-02-15 08:20:20 UTC
In my case during Xorg start