Created attachment 180619 [details]
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.