Date: Thu, 22 Jan 2015 12:02:01 +0100 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= <trasz@FreeBSD.org> To: current@FreeBSD.org Subject: Suspend/resume with i915. Message-ID: <20150122110201.GA3996@brick.home>
next in thread | raw e-mail | index | archive | help
I'm trying to fix resume on my T61, broken by some change several
months ago; according to pciconf it's 'Mobile GM965/GL960 Integrated
Graphics Controller (primary)'. It's running current CURRENT and
up to date packages.
Suspend and resume makes Xorg do something weird - there is screen
corruption, or rather window corruption. The GNOME 3 desktop looks
pretty normal, except that gnome-terminal (launched before suspend)
window looks as if the buffer layout changed underneath it; for example,
instead of one flashing cursor there are several, horizontally, across
the window. New windows are simply black. No segv.
Setting kern.vt.suspendswitch=0 makes the behaviour disappear, replaced
by segmentation faults of gnome-shell. With stock gdb it looks like this:
#0 0x000000081518d7b3 in __driDriverGetExtensions_i965 () from /usr/local/lib/dri/i965_dri.so
#1 0x00000008151353ef in __driDriverGetExtensions_i965 () from /usr/local/lib/dri/i965_dri.so
#2 0x0000000804dfe70c in cogl_framebuffer_clear4f () from /usr/local/lib/libcogl.so.20
With gdb from ports and graphics/dri port rebuilt with debug flags, using
'make CFLAGS="-O0 -ggdb" WITH_DEBUG=yes STRIP= clean all deinstall reinstall',
it makes more sense:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 804806400 (LWP 100123)]
0x0000000805bb490b in get_stencil_miptree (irb=0x80483fe80)
at brw_misc_state.c:225
225 if (irb->mt->stencil_mt)
(gdb) where
#0 0x0000000805bb490b in get_stencil_miptree (irb=0x80483fe80)
at brw_misc_state.c:225
#1 0x0000000805bb3cbd in brw_workaround_depthstencil_alignment (
brw=0x804907028, clear_mask=18) at brw_misc_state.c:241
#2 0x0000000805b3355e in brw_clear (ctx=0x804907028, mask=18)
at brw_clear.c:235
#3 0x000000080568309e in _mesa_Clear (mask=16640)
at ../../src/mesa/main/clear.c:225
There are several suggested fixes for this, like those:
https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/master/media-libs/mesa/files/10.3-dri-i965-Return-NULL-if-we-don-t-have-a-miptree.patch
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-os-checkins/5HAd07ICk94
They don't seem to work, though, and the Mesa codebase doesn't exactly
look promising.
Now, what I've noticed is that if I switch to VT0 (ctrl-alt-f1) and then
suspend, the resume works flawlessly, and after switching to Xorg it runs
without any problems either. This got me thinking... Adding this:
/usr/sbin/vidcontrol -s 1 < /dev/ttyv0
to /etc/rc.suspend, with kern.vt.suspendswitch=0, prevents suspend with
Xorg from breaking things, with a drawback that one has to manually switch
back to Xorg after resume.
So, questions:
1. Are there any patches that could actually fix suspend/resume with Xorg,
instead of working around it?
2. Does the rc.suspend workaround seem like a proper one? My theory is
that it works better than kern.vt.suspendswitch=1 because it gives
Xserver a chance to properly release VT, or "deinitialize stuff".
Does it make sense? If so, I could add "vidcontrol -w" to return
number of current console, and use it, together with "vidcontrol -s",
in rc.suspend and rc.resume scripts, if kern.vty.suspendswitch is
enabled. That would provide a properly working workaround without
need for any manual configuration.
3. This is a weird one - the workaround works when closing a lid, and
when doing "acpiconf -s3" in gnome-terminal window, but does not work
when suspend was initiated by Fn-F4. Any ideas?
All feedback is welcome.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150122110201.GA3996>