Bug 193269 - panic: kdb_switch: did not reenter debugger (from sysctl debug.kdb.enter=1 w/ i915kms)
Summary: panic: kdb_switch: did not reenter debugger (from sysctl debug.kdb.enter=1 w/...
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
Depends on:
Reported: 2014-09-03 00:56 UTC by Ed Maste
Modified: 2014-09-18 14:38 UTC (History)
2 users (show)

See Also:

USe DELAY() when DDB is active (531 bytes, patch)
2014-09-04 17:06 UTC, Jean-Sébastien Pédron
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ed Maste freebsd_committer 2014-09-03 00:56:09 UTC
X11 w/ i915, "sysctl debug.kdb.enter=1" from an xterm results in the following panic:

#3  0xffffffff8090dc43 in panic (fmt=0x0)
    at /tank/emaste/src/freebsd/sys/kern/kern_shutdown.c:675
#4  0xffffffff80916ed4 in mi_switch (flags=<value optimized out>,
    newtd=<value optimized out>)
    at /tank/emaste/src/freebsd/sys/kern/kern_synch.c:424
#5  0xffffffff80953262 in sleepq_switch (wchan=<value optimized out>,
    pri=<value optimized out>)
    at /tank/emaste/src/freebsd/sys/kern/subr_sleepqueue.c:552
#6  0xffffffff809537c3 in sleepq_timedwait (wchan=0xffffffff815bdc82, pri=0)
    at /tank/emaste/src/freebsd/sys/kern/subr_sleepqueue.c:666
#7  0xffffffff8091670a in _sleep (ident=<value optimized out>,
    lock=<value optimized out>, priority=<value optimized out>,
    wmesg=<value optimized out>, sbt=<value optimized out>,
    pr=<value optimized out>)
    at /tank/emaste/src/freebsd/sys/kern/kern_synch.c:251
#8  0xffffffff80916be4 in pause_sbt (wmesg=0xffffffff8205e826 "915vbl",
    sbt=<value optimized out>, pr=0, flags=256)
    at /tank/emaste/src/freebsd/sys/kern/kern_synch.c:380
#9  0xffffffff8202d0d8 in intel_wait_for_vblank (dev=<value optimized out>,
    pipe=<value optimized out>)
    at /tank/emaste/src/freebsd/sys/modules/drm2/i915kms/../../../dev/drm2/i915/
#10 0xffffffff82035459 in intel_pipe_set_base (crtc=0xfffff80012ef8800, x=0,
    y=0, old_fb=0xfffff800141bcd80)
    at /tank/emaste/src/freebsd/sys/modules/drm2/i915kms/../../../dev/drm2/i915/
#11 0xffffffff8207e960 in drm_crtc_helper_set_config (set=0xfffff8025603e208)
    at /tank/emaste/src/freebsd/sys/modules/drm2/drm2/../../../dev/drm2/drm_crtc
#12 0xffffffff82085b7c in vt_kms_postswitch (arg=<value optimized out>)
    at /tank/emaste/src/freebsd/sys/modules/drm2/drm2/../../../dev/drm2/drm_fb_h
#13 0xffffffff807bae53 in vt_window_switch (vw=0xffffffff81467cb8)
    at /tank/emaste/src/freebsd/sys/dev/vt/vt_core.c:387
#14 0xffffffff807b9123 in vtterm_cngrab (tm=<value optimized out>)
    at /tank/emaste/src/freebsd/sys/dev/vt/vt_core.c:1238
#15 0xffffffff808c15c5 in cngrab ()
    at /tank/emaste/src/freebsd/sys/kern/kern_cons.c:360
#16 0xffffffff809468d3 in kdb_trap (type=3, code=0, tf=<value optimized out>)
    at /tank/emaste/src/freebsd/sys/kern/subr_kdb.c:651
#17 0xffffffff80d23c02 in trap (frame=0xfffffe046320e6e0)
    at /tank/emaste/src/freebsd/sys/amd64/amd64/trap.c:542
#18 0xffffffff80d059e2 in calltrap ()
    at /tank/emaste/src/freebsd/sys/amd64/amd64/exception.S:231
#19 0xffffffff80946b71 in kdb_sysctl_enter (oidp=<value optimized out>,
    arg1=<value optimized out>, arg2=-2180180285808, req=<value optimized out>)
    at cpufunc.h:63
#20 0xffffffff80919828 in sysctl_root_handler_locked (oid=0xffffffff8148bf80,
    arg1=0x0, arg2=0, req=0xfffffe046320e868)
    at /tank/emaste/src/freebsd/sys/kern/kern_sysctl.c:153
Comment 1 Andriy Gapon freebsd_committer 2014-09-03 13:15:20 UTC
kdb_trap context places certain requirements on code that can be executed.
Apparently drm code (used via vt) is not aware of those requirements.
The easiest solution is probably to amend pause_sbt() to take the 'cold' code path for kdb_active case as well.
Comment 2 Jean-Sébastien Pédron freebsd_committer 2014-09-04 17:06:21 UTC
Created attachment 146807 [details]
USe DELAY() when DDB is active

Andriy, you were right. Using DELAY() instead of pause() when kdb_active is true fixes the panic for me. I attached the patch I used.

Could you please elaborate on the kdb_trap requirements? What should we do in DRM to fix this?
Comment 3 commit-hook freebsd_committer 2014-09-08 08:45:49 UTC
A commit references this bug:

Author: dumbbell
Date: Mon Sep  8 08:44:50 UTC 2014
New revision: 271253
URL: http://svnweb.freebsd.org/changeset/base/271253

  pause_sbt(): Take the cold path (ie. use DELAY()) if KDB is active

  This fixes a panic in the i915 driver when one uses debug.kdb.enter=1
  under vt(4).

  PR:		193269
  Reported by:	emaste@
  Submitted by:	avg@
  MFC after:	3 days

Comment 4 commit-hook freebsd_committer 2014-09-18 14:38:41 UTC
A commit references this bug:

Author: dumbbell
Date: Thu Sep 18 14:38:21 UTC 2014
New revision: 271769
URL: http://svnweb.freebsd.org/changeset/base/271769

  vt(4): Merge several bug fixes and improvements

  SVN revisions in this MFC:
    269779 270705 270706 271180 271250 271253 271682 271684

  Detailed commit list:

    fbd: Fix a bug where vt_fb_attach() success would be considered a failure

    vt_fb_attach() currently always returns 0, but it could return a code
    defined in errno.h. However, it doesn't return a CN_* code. So checking
    its return value against CN_DEAD (which is 0) is incorrect, and in this
    case, a success becomes a failure.

    The consequence was unimportant, because the caller (drm_fb_helper.c)
    would only log an error message in this case. The console would still

    Approved by:	nwhitehorn

    vt(4): Add cngrab() and cnungrab() callbacks

    They are used when a panic occurs or when entering a DDB session for

    cngrab() forces a vt-switch to the console window, no matter if the
    original window is another terminal or an X session. However, cnungrab()
    doesn't vt-switch back to the original window currently.

    drm: Don't "taskqueue" vt-switch if under DDB/panic situation

    If DDB is active, we can't use a taskqueue thread to switch away from
    the X window, because this thread can't run.

    Reviewed by:	ray@
    Approved by:	ray@

    vt_vga: vd_setpixel_t and vd_drawrect_t are noop in text mode

    vt(4): Change the terminal and buffer sizes, even without a font

    This fixes a bug where scroll lock would not work for tty #0 when using
    vt_vga's textmode. The reason was that this window is created with a
    static 256x100 buffer, larger than the real size of 80x25.

    Now, in vt_change_font() and vt_compute_drawable_area(), we still
    perform operations even of the window has no font loaded (this is the
    case in textmode here vw->vw_font == NULL). One of these operation
    resizes the buffer accordingly.

    In vt_compute_drawable_area(), we take the terminal size as is (ie.
    80x25) for the drawable area.

    The font argument to vt_set_border() is removed (it was never used) and
    the code now uses the computed drawable area instead of re-doing its own

    Reported by:	Harald Schmalzbauer <h.schmalzbauer_omnilan.de>
    Tested by:	Harald Schmalzbauer <h.schmalzbauer_omnilan.de>

    pause_sbt(): Take the cold path (ie. use DELAY()) if KDB is active

    This fixes a panic in the i915 driver when one uses debug.kdb.enter=1
    under vt(4).

    PR:		193269
    Reported by:	emaste@
    Submitted by:	avg@

    vt(4): Fix a LOR which occurs during a call to vt_upgrade()

    Reported by:	kib@
    Review:		https://reviews.freebsd.org/D785
    Reviewed by:	ray@
    Approved by:	ray@

    vt(4): Use vt_fb_drawrect() and vt_fb_setpixel() in all vt_fb-derivative

    Review:		https://reviews.freebsd.org/D789
    Reviewed by:	nwhitehorn
    Approved by:	nwhitehorn

  Approved by:	re (gjb)

_U  stable/10/