From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 07:50:23 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E7C01065675 for ; Sun, 29 Mar 2009 07:50:23 +0000 (UTC) (envelope-from lstewart@room52.net) Received: from outbound.icp-qv1-irony-out4.iinet.net.au (outbound.icp-qv1-irony-out4.iinet.net.au [203.59.1.150]) by mx1.freebsd.org (Postfix) with ESMTP id 1891E8FC13 for ; Sun, 29 Mar 2009 07:50:22 +0000 (UTC) (envelope-from lstewart@room52.net) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAI/Ezkl8qF1T/2dsb2JhbAC7WwGNWIIsHAGBMQY X-IronPort-AV: E=Sophos;i="4.38,441,1233500400"; d="scan'208";a="332377691" Received: from unknown (HELO lawrence1.loshell.room52.net) ([124.168.93.83]) by outbound.icp-qv1-irony-out4.iinet.net.au with ESMTP; 29 Mar 2009 15:50:20 +0800 Message-ID: <49CF283C.6050003@room52.net> Date: Sun, 29 Mar 2009 18:50:20 +1100 From: Lawrence Stewart User-Agent: Thunderbird 2.0.0.21 (X11/20090326) MIME-Version: 1.0 To: Robert Noland References: <49CB70BD.3040607@boland.org> <1238086577.1792.30.camel@balrog.2hip.net> <49CC43C4.7030905@swin.edu.au> <1238126285.8491.2.camel@balrog.2hip.net> <179b97fb0903262114i511ec294ief17475d673e70c9@mail.gmail.com> <1238136987.8491.173.camel@balrog.2hip.net> <179b97fb0903270014u12e5fd10w46a18c36efa9ddf8@mail.gmail.com> <1238188110.8491.194.camel@balrog.2hip.net> In-Reply-To: <1238188110.8491.194.camel@balrog.2hip.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Brandon Gooch , Michiel Boland , FreeBSD Current , Mattia Rossi Subject: Re: still problems with intel video X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 29 Mar 2009 07:50:24 -0000 Robert Noland wrote: [snip] > > Ok, this is a complete patch against HEAD. It has even more debugging > around suspend/resume and also grabs the hardware lock when it starts to > suspend or resume. I'm tempted to just grab the lock when we start > suspend and not release it until resume is complete, but it looks like > something is triggering a vt switch and we could deadlock on that if I > don't drop the lock. I should be able to tell a little more from the > drm debug output of this patch. I'm having similar problems as described in this thread with 8-CURRENT amd64 r190518 on a Toshiba Portege R600 laptop which has a "Mobile Intel® GM45 Express Chipset". The machine is brand new and has been built using ports from scratch 2 days ago. Relevant pciconf output: vgapci1@pci0:0:2:1: class=0x038000 card=0x000c1179 chip=0x2a438086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' class = display cap 01[d0] = powerspec 3 supports D0 D3 current D0 With DRM MSI enabled, everything runs fine in kde4, but switching to console and back causes X to start running dog slow. On reboot/shutdown from kde, X doesn't die properly, and I get crazy psychedelic colours all over the LCD before reboot. Robert, I rejigged your patch to make it apply cleanly to r190518 (you can grab the new patch at the URL below) so that I could take it for a spin. I've created tons of debug output obtained with DRM_DEBUG in my kernel conf and with your patch. Grab the data along with some more general system info from: http://people.freebsd.org/~lstewart/misc/intel_debug/ Note that I start kdm at boot time from /etc/ttys. startup.txt captures debug output as X/kdm fire up. kdm_to_console.txt captures the debug output of a switch to console (ttyv1) from the kdm login prompt. console_to_kdm.txt captures the debug output of a switch from console (ttyv1) back to kdm login prompt on ttyv8. shutdown.txt captures debug output after I tell kdm to reboot the machine. This was done after the above 2 tests, so X is in the weird slow state. /var/log/messages says that X core dumps when it tries to shutdown. Running gdb on the core file yields some info. See Xorg_gdb.txt for the backtrace. I'm now set up to do any further debugging and patch testing on this machine so please let me know if there's anything I can do (beating Intel with a stick included). Cheers, Lawrence