Bug 213334 - vtterm_cngrab is broken on kms-enabled systems when entering kdb
Summary: vtterm_cngrab is broken on kms-enabled systems when entering kdb
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
Keywords: vt
Depends on:
Reported: 2016-10-09 10:35 UTC by Andriy Gapon
Modified: 2020-05-22 11:18 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Andriy Gapon freebsd_committer 2016-10-09 10:35:01 UTC
This stack trace tells it all:
(kgdb) bt
#0  doadump (textdump=1) at pcpu.h:222
#1  0xffffffff80a424a5 in kern_reboot (howto=<value optimized out>) at /usr/src/sys/kern/kern_shutdown.c:366
#2  0xffffffff80a42a7b in vpanic (fmt=<value optimized out>, ap=<value optimized out>) at /usr/src/sys/kern/kern_shutdown.c:759
#3  0xffffffff80a428b6 in kassert_panic (fmt=<value optimized out>) at /usr/src/sys/kern/kern_shutdown.c:649
#4  0xffffffff80a1f4ae in malloc (size=1712, mtp=0xffffffff8309c6a0, flags=257) at /usr/src/sys/kern/kern_malloc.c:475
#5  0xffffffff8306b71a in drm_crtc_helper_set_config (set=<value optimized out>) at /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_crtc_helper.c:596
#6  0xffffffff83071fae in vt_kms_postswitch (arg=<value optimized out>) at /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_fb_helper.c:344
#7  0xffffffff808d4b5b in vt_window_switch (vw=0xffffffff818e1400) at /usr/src/sys/dev/vt/vt_core.c:540
#8  0xffffffff808d2620 in vtterm_cngrab (tm=<value optimized out>) at /usr/src/sys/dev/vt/vt_core.c:1465
#9  0xffffffff809e8872 in cngrab () at /usr/src/sys/kern/kern_cons.c:368
#10 0xffffffff80a841e9 in kdb_trap (type=<value optimized out>, code=<value optimized out>, tf=<value optimized out>) at /usr/src/sys/kern/subr_kdb.c:651
#11 0xffffffff81003732 in nmi_call_kdb (cpu=0, type=19, code=<value optimized out>, frame=0xffffffff81d73d50, do_panic=false) at /usr/src/sys/x86/x86/cpu_machdep.c:547
#12 0xffffffff8100f32f in nmi_call_kdb_smp (type=0, code=0, frame=0x0, do_panic=<value optimized out>) at /usr/src/sys/x86/x86/mp_x86.c:1228
#13 0xffffffff8100375c in nmi_handle_intr (type=0, code=0, frame=0x0, panic=<value optimized out>) at /usr/src/sys/x86/x86/cpu_machdep.c:564
#14 0xffffffff80eb57f6 in trap (frame=0xffffffff81d73d50) at /usr/src/sys/amd64/amd64/trap.c:547
#15 0xffffffff80e96603 in nmi_calltrap () at /usr/src/sys/amd64/amd64/exception.S:510
#16 0xffffffff81003216 in acpi_cpu_c1 () at /usr/src/sys/x86/x86/cpu_machdep.c:130
Previous frame inner to this frame (corrupt stack?)

cngrab() can be called from all kinds of contexts and it should be able to handle that.
Unfortunately, if a KMS-enabled graphics driver is used, then vt_kms_postswitch() calls drm code that can only work in an unrestricted context.  It can not work in an interrupt (including NMI context).
Comment 1 Andriy Gapon freebsd_committer 2016-10-09 11:44:24 UTC
It seems that fixing this for real could be hard, so maybe we could start with setting CN_FLAG_NODEBUG in the affected configurations.
Although, it seems that the latest Linux DRM code has the problem fixed.
Comment 2 Matthew Macy 2016-10-10 04:28:30 UTC
(In reply to Andriy Gapon from comment #1)
drm-next-* work better, but it's extremely difficult to properly fix because there end up being all manner of sleeps() and synchronization in the process of switching.
Comment 3 Andriy Gapon freebsd_committer 2020-05-22 11:18:37 UTC
drm/kms is no longer in base...