Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 08 Mar 2017 05:06:38 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-bugs@FreeBSD.org
Subject:   [Bug 217625] Kernel panic during suspend to RAM from X11 context
Message-ID:  <bug-217625-8@https.bugs.freebsd.org/bugzilla/>

index | next in thread | raw e-mail

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217625

            Bug ID: 217625
           Summary: Kernel panic during suspend to RAM from X11 context
           Product: Base System
           Version: 11.0-RELEASE
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs@FreeBSD.org
          Reporter: aksyom@gmail.com

Created attachment 180619
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=180619&action=edit
Xorg log and output of pciconf -lbev

These problems started probably after I upgraded all my packages, which then
upgraded the X11 intel DDX driver. I am quite sure suspend to RAM worked fine
before that.

If I do suspend to RAM when switched to console first, there is no problem.

Previously, probably before the intel DDX upgrade, the system would switch to
console tty, then suspend, and during resume would switch back to X11 context.

I managed to get a crash dump. Here is a backtrace:
(kgdb) bt
#0  doadump (textdump=<value optimized out>) at pcpu.h:221
#1  0xffffffff80ad8ee9 in kern_reboot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:366
#2  0xffffffff80ad949b in vpanic (fmt=<value optimized out>, ap=<value
optimized out>) at /usr/src/sys/kern/kern_shutdown.c:759
#3  0xffffffff80ad92d3 in panic (fmt=0x0) at
/usr/src/sys/kern/kern_shutdown.c:690
#4  0xffffffff80fa1d51 in trap_fatal (frame=0xfffffe022367c5a0, eva=12) at
/usr/src/sys/amd64/amd64/trap.c:841
#5  0xffffffff80fa1f43 in trap_pfault (frame=0xfffffe022367c5a0, usermode=0) at
/usr/src/sys/amd64/amd64/trap.c:691
#6  0xffffffff80fa14ec in trap (frame=0xfffffe022367c5a0) at
/usr/src/sys/amd64/amd64/trap.c:442
#7  0xffffffff80f841c1 in calltrap () at
/usr/src/sys/amd64/amd64/exception.S:236
#8  0xffffffff829e0c05 in ironlake_crtc_enable (crtc=<value optimized out>) at
/usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_display.c:3136
#9  0xffffffff829dabcd in intel_set_mode (crtc=<value optimized out>,
mode=0xfffff800069f2200, x=0, y=0, fb=0xfffff800954546b0)
    at
/usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_display.c:7993
#10 0xffffffff829ea13d in intel_crtc_set_config (set=<value optimized out>) at
/usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_display.c:8284
#11 0xffffffff82a59f8e in vt_restore_fbdev_mode (arg=<value optimized out>,
pending=<value optimized out>)
    at /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_fb_helper.c:344
#12 0xffffffff80b3644a in taskqueue_run_locked (queue=<value optimized out>) at
/usr/src/sys/kern/subr_taskqueue.c:449
#13 0xffffffff80b37358 in taskqueue_thread_loop (arg=<value optimized out>) at
/usr/src/sys/kern/subr_taskqueue.c:703
#14 0xffffffff80a900d5 in fork_exit (callout=0xffffffff80b37270
<taskqueue_thread_loop>, arg=0xffffffff81e144b0, frame=0xfffffe022367cac0) at
/usr/src/sys/kern/kern_fork.c:1038
#15 0xffffffff80f846fe in fork_trampoline () at
/usr/src/sys/amd64/amd64/exception.S:611
#16 0x0000000000000000 in ?? ()

I've attached some files which describe my setup:
- Xorg.0.log.old - file /var/log/Xorg.0.log.old
- pciconf.txt - output of pciconf -lbev

The attached files are captured or created just after the reboot from crash.

Because the attachment size limit is 1M, I have uploaded the crash dump here:
https://drive.google.com/open?id=0B3u1MJ_t35aQazVQYVZZaFJnRjQ

Can somebody check if there's anything that could be done to make this work?
Unless this is fixed, I will have to shadow the zzz -utility with a shell
script that forces a vty switch to console before invoking the original zzz.
But that is an ugly kludge in my opinion.

At the time of crash I had not started web browsers or any other software which
would keep password or other similar things in memory, so I hope that crash
dump don't contain any info that can be used by randoms and/or botnets to hack
me.

-- 
You are receiving this mail because:
You are the assignee for the bug.

help

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-217625-8>