Bug 247166 - graphics/drm-devel-kmod: panic with i915kms on -current
Summary: graphics/drm-devel-kmod: panic with i915kms on -current
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-x11 (Nobody)
Depends on:
Reported: 2020-06-11 12:28 UTC by Erik Inge Bolsø
Modified: 2020-06-16 13:23 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (x11)

Picture of panic kdb screen (259.77 KB, image/jpeg)
2020-06-11 12:28 UTC, Erik Inge Bolsø
no flags Details
pciconf -lv (5.48 KB, text/plain)
2020-06-11 13:02 UTC, Erik Inge Bolsø
no flags Details
dmesg with verbose boot (79.48 KB, text/plain)
2020-06-11 13:03 UTC, Erik Inge Bolsø
no flags Details
quick-and-dirty.patch (5.71 KB, patch)
2020-06-15 22:15 UTC, Vladimir Kondratyev
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Erik Inge Bolsø 2020-06-11 12:28:57 UTC
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.
Comment 1 Emmanuel Vadot freebsd_committer 2020-06-11 12:37:21 UTC
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
Comment 2 Erik Inge Bolsø 2020-06-11 13:01:37 UTC
Happened after a while, while resizing/dragging a window in KDE. Cannot reproduce reliably.
Comment 3 Erik Inge Bolsø 2020-06-11 13:02:19 UTC
Created attachment 215445 [details]
pciconf -lv
Comment 4 Erik Inge Bolsø 2020-06-11 13:03:28 UTC
Created attachment 215446 [details]
dmesg with verbose boot
Comment 5 Vladimir Kondratyev freebsd_committer 2020-06-11 15:31:36 UTC
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
Comment 6 Emmanuel Vadot freebsd_committer 2020-06-11 15:42:33 UTC
(In reply to Vladimir Kondratyev from comment #5)
Could you open a issue (maybe with some workaround) in github ?
Comment 7 Vladimir Kondratyev freebsd_committer 2020-06-11 15:55:37 UTC
(In reply to Emmanuel Vadot from comment #6)
I'll do it
Comment 8 Vladimir Kondratyev freebsd_committer 2020-06-11 21:31:37 UTC
(In reply to Emmanuel Vadot from comment #6)
Comment 9 Vladimir Kondratyev freebsd_committer 2020-06-15 22:15:49 UTC
Created attachment 215592 [details]

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.
Comment 10 Erik Inge Bolsø 2020-06-16 13:23:17 UTC
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.