Bug 247166 - graphics/drm-devel-kmod: panic with i915kms on -current
Summary: graphics/drm-devel-kmod: panic with i915kms on -current
Status: Closed FIXED
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-09-17 09:18 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.
Comment 11 Emmanuel Vadot freebsd_committer 2020-09-17 09:18:37 UTC
Closing this, please reopen if you're able to reproduce with latest version of FreeBSD-CURRENT and drm-current-kmod (v5.4.62).