From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 11:02:07 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 43F4F819 for ; Thu, 22 Jan 2015 11:02:07 +0000 (UTC) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C9F1FFCC for ; Thu, 22 Jan 2015 11:02:06 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id y19so998066wgg.11 for ; Thu, 22 Jan 2015 03:02:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:mail-followup-to :mime-version:content-type:content-disposition:user-agent; bh=qyJ+dCWNJOX/am9vI6Ou0/DoylniuEL31AaieIlJVeg=; b=LxT41TfmH4jAN0t758wI9/5RMKhfVzhWSe//qz28j0YvbDVMfKNyRCMCwQgt5Ql5iK 0BtSGATnU2liwHh/Oixa5EM8A7WruuFdIqRt1Nyq8julhuEmQqdKH4cslj9r5OdxJEeT 8uZK+mgO8CAK88AQyFp3D8e+4vwsTtm2rNYbzPjOrsfxHKL625oOl69WKnSRifQrqShX +EgLfum/BkaIyPSJpuZxRI4YePCk9uAP6gXrWfFKjwcPxCJNnSkNxjHifSD8Rg2PbXcM 4RK69MZuNld9jRpVj6VwxNrz8u6muJb/DhkUT48EhtTJe/+RpTZkCoB8+7T+dryPTj52 PQZw== X-Received: by 10.194.190.39 with SMTP id gn7mr1968828wjc.30.1421924525221; Thu, 22 Jan 2015 03:02:05 -0800 (PST) Received: from brick.home (abpi241.neoplus.adsl.tpnet.pl. [83.8.50.241]) by mx.google.com with ESMTPSA id h13sm2559986wiw.4.2015.01.22.03.02.04 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Jan 2015 03:02:04 -0800 (PST) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Thu, 22 Jan 2015 12:02:01 +0100 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: current@FreeBSD.org Subject: Suspend/resume with i915. Message-ID: <20150122110201.GA3996@brick.home> Mail-Followup-To: current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 11:02:07 -0000 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.