Created attachment 215444 [details] Picture of panic kdb screen My laptop running CURRENT paniced today. Nothing saved in /var/crash. Added a picture of the crash screen. - 13.0-CURRENT r361784 - drm-devel-kmod 5.2.g20200602 Sleep with spinlock/critical section held of some kind.
Do that happens at load ? after a while ? Can you reproduce it reliably ? Also please attach full dmesg (preferably after a verbose boot, boot -v) and pciconf -lv output
Happened after a while, while resizing/dragging a window in KDE. Cannot reproduce reliably.
Created attachment 215445 [details] pciconf -lv
Created attachment 215446 [details] dmesg with verbose boot
The panic is easy reproducible on KabyLake. All you need is to run guc firmware or vp8enc from multimedia/libva-utils. Both of them trigger it instantly. I workarounded it with updating linux_reservation.c to up to date version (really to 5.3) and moving critical section start in reservation_object_add_shared_fence() routine down to RCU_INIT_POINTER macro. There were lot of dma_fence changes in 5.0-5.4 timeframe, so it may have sense to start fixing the bug after drm-kmod reaches v5.4
(In reply to Vladimir Kondratyev from comment #5) Thanks, Could you open a issue (maybe with some workaround) in github ?
(In reply to Emmanuel Vadot from comment #6) I'll do it
(In reply to Emmanuel Vadot from comment #6) https://github.com/freebsd/drm-kmod/issues/9
Created attachment 215592 [details] quick-and-dirty.patch Try enclosed patch. I do not know why intel calls schedule_work() and kfree() with preemption disabled. If it is intended then we can copy parts of the patch in to drm-kmod.
Have been running a patched kernel for a few hours with no issues. So it doesn't make things worse, at least. :) Have not been able to reproduce the crash with or without the patch, so hard to tell if there is an improvement. Will let you know if it crashes.
Closing this, please reopen if you're able to reproduce with latest version of FreeBSD-CURRENT and drm-current-kmod (v5.4.62). Thanks.