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/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217625 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=3D180619&action= =3Dedit 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 fi= ne 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 conte= xt. I managed to get a crash dump. Here is a backtrace: (kgdb) bt #0 doadump (textdump=3D<value optimized out>) at pcpu.h:221 #1 0xffffffff80ad8ee9 in kern_reboot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:366 #2 0xffffffff80ad949b in vpanic (fmt=3D<value optimized out>, ap=3D<value optimized out>) at /usr/src/sys/kern/kern_shutdown.c:759 #3 0xffffffff80ad92d3 in panic (fmt=3D0x0) at /usr/src/sys/kern/kern_shutdown.c:690 #4 0xffffffff80fa1d51 in trap_fatal (frame=3D0xfffffe022367c5a0, eva=3D12)= at /usr/src/sys/amd64/amd64/trap.c:841 #5 0xffffffff80fa1f43 in trap_pfault (frame=3D0xfffffe022367c5a0, usermode= =3D0) at /usr/src/sys/amd64/amd64/trap.c:691 #6 0xffffffff80fa14ec in trap (frame=3D0xfffffe022367c5a0) 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=3D<value optimized out= >) at /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_display.c:31= 36 #9 0xffffffff829dabcd in intel_set_mode (crtc=3D<value optimized out>, mode=3D0xfffff800069f2200, x=3D0, y=3D0, fb=3D0xfffff800954546b0) at /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_display.c:79= 93 #10 0xffffffff829ea13d in intel_crtc_set_config (set=3D<value optimized out= >) at /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_display.c:82= 84 #11 0xffffffff82a59f8e in vt_restore_fbdev_mode (arg=3D<value optimized out= >, pending=3D<value optimized out>) at /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_fb_helper.c:344 #12 0xffffffff80b3644a in taskqueue_run_locked (queue=3D<value optimized ou= t>) at /usr/src/sys/kern/subr_taskqueue.c:449 #13 0xffffffff80b37358 in taskqueue_thread_loop (arg=3D<value optimized out= >) at /usr/src/sys/kern/subr_taskqueue.c:703 #14 0xffffffff80a900d5 in fork_exit (callout=3D0xffffffff80b37270 <taskqueue_thread_loop>, arg=3D0xffffffff81e144b0, frame=3D0xfffffe022367ca= c0) 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 her= e: https://drive.google.com/open?id=3D0B3u1MJ_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 w= hich 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 h= ack me. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-217625-8>