From owner-freebsd-x11@FreeBSD.ORG Tue Jul 12 11:11:12 2011 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96F07106566B for ; Tue, 12 Jul 2011 11:11:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 35E6B8FC16 for ; Tue, 12 Jul 2011 11:11:11 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p6CBB8KB083419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jul 2011 14:11:08 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p6CBB8TH093453; Tue, 12 Jul 2011 14:11:08 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p6CBB8fi093452; Tue, 12 Jul 2011 14:11:08 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 12 Jul 2011 14:11:08 +0300 From: Kostik Belousov To: Andrey Kosachenko Message-ID: <20110712111108.GG43872@deviant.kiev.zoral.com.ua> References: <20110708184413.GD48734@deviant.kiev.zoral.com.ua> <20110709174612.GN48734@deviant.kiev.zoral.com.ua> <4E1A0362.8050808@gmail.com> <20110710212339.GO43872@deviant.kiev.zoral.com.ua> <4E1B56E7.4090801@gmail.com> <20110712081704.GB43872@deviant.kiev.zoral.com.ua> <4E1C295D.2080008@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ixNtouB4hv1hrEz3" Content-Disposition: inline In-Reply-To: <4E1C295D.2080008@gmail.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-x11@freebsd.org Subject: Re: Intel GPU kernel driver X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 11:11:12 -0000 --ixNtouB4hv1hrEz3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 12, 2011 at 02:00:45PM +0300, Andrey Kosachenko wrote: > On 12.07.2011 11:17, Kostik Belousov wrote: > >>>>- switching between vts (Ctrl+Alt+F[1-9]) doesn't work over here, > >>>>attempt to switch to consoles within range [1-8] leads to garbled scr= een > >>>>(https://lh4.googleusercontent.com/-WmDhn1X-Ze0/Thn-O5dfeiI/AAAAAAAAA= BM/WIX3co3DQaM/s720/20110710_003-1.jpeg) > >>>>though 9-th (occupied by X) is always displayed properly; > >Yes, VT switch handling is not implemented. >=20 > Okay, got it (just expressed my observations) >=20 > >>Also not sure that X actually operates w/o acceleration: the following > >>output makes me think so: > >> > >># env LIBGL_DEBUG=3Dverbose sh -c 'glxinfo 2>&1' | egrep '(render|Drive= r)' > >>direct rendering: Yes > >>OpenGL renderer string: Mesa DRI Intel(R) Ironlake Mobile > >> GL_EXT_vertex_array_bgra, GL_NV_conditional_render, > >If OpenGL apps work, and not cause the X server to die with SIGBUS, > >then yes, most likely acceleration works. >=20 > Yeap, agree. Unfortunately I hadn't appropriate apps at my hand at that= =20 > very moment. Though freaking artificial glxgears ran w/o issues (sorry=20 > for my ignorance... I'm not a fan of games, GL neat features/effects and= =20 > stuff like that, so if you can recommend smth. to test it thoroughly=20 > I'll do it and report the results) Working glxgears with direct rendering reported 'on' is enough to make sure. >=20 > >> > >>Additional information: > >>- pciconf -lvb: http://pastebin.com/YT8wUBiZ > >So this is another Ironlake. >=20 > Hm... not sure if I got this properly. In the first post I mentioned=20 > that there is a laptop "with integrated Intel graphics card (Ironlake,=20 > 0x00468086)". pciconf -lvb output also reports "chip=3D0x00468086". AFAIK= =20 > there are two types of chips: 0x00428086 (a.k.a. "D" (desktop?)) and=20 > 0x00468086 (a.k.a. "M" (mobile?)). And I've got exactly the second one. My observation is that people who report (some) success with the patch all using Ironlake machines. This is not much surprising due to my test machine being Ironlake. I just hold a little hope that there is somebody who got it working on !Ironlake. >=20 > >> > >>- dmesg output (with DE effects enabled, leads to garbled screen): > >>http://pastebin.com/DU3RvzTi > >> > >>- dmesg output (failsafe DE session): http://pastebin.com/f4gghA6E > >No useful information there. >=20 > yeap, the second dmesg's output (failsafe) is clean and mentioned just=20 > for comparison. However the first one (http://pastebin.com/DU3RvzTi)=20 > contains suspicious entries (for instance line #333, #340, #367 and so=20 > forth). So I thought it could be helpful (though you considered it=20 > useless... let me know if you want to acquire more info) The timeout on gmbus usually means that connector has no load attached to it. It is a usual and expected situation during connection polling, that KMS performs periodically to note new monitors connected which might failed to cause interrupt on attachment. What is somewhat puzzling is the failure to create bit-banging fallback iic buses. You might debug this, I have no idea why it is failing. Anyway, bbbus attachment failure is KMS issue, and has nothing to do with GEM. >=20 > >> > >>- and just in case X logs (with ModeDebug=3D"true"): > >>http://pastebin.com/iEPxm8ib > >When did the X server segfaulted ? >=20 > X segfaulted on attempt to enable desktop effects (presumes usage of=20 > composite extension). Both aforementioned logs (Xorg.log=20 > (http://pastebin.com/iEPxm8ib) and first dmesg output=20 > (http://pastebin.com/DU3RvzTi) were collected within 2-5 seconds right=20 > after X segfaulted. >=20 > Also, forgot to mention that hw.dri.0.info.i915_error_state didn't=20 > contain any errors. This makes me almost certain that the issue is in userland. --ixNtouB4hv1hrEz3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk4cK8sACgkQC3+MBN1Mb4gjgACeO5gVJnA2MMFWnMy1y5qor4Dj VAQAoIEm4zxpjZbcmaRai+zIvHY5dgIC =frgr -----END PGP SIGNATURE----- --ixNtouB4hv1hrEz3--