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. _______________________________________________ email@example.com mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"