Date: Sun, 29 Mar 2009 18:50:20 +1100 From: Lawrence Stewart <lstewart@room52.net> To: Robert Noland <rnoland@freebsd.org> Cc: Brandon Gooch <jamesbrandongooch@gmail.com>, Michiel Boland <michiel@boland.org>, FreeBSD Current <freebsd-current@freebsd.org>, Mattia Rossi <mrossi@swin.edu.au> Subject: Re: still problems with intel video Message-ID: <49CF283C.6050003@room52.net> In-Reply-To: <1238188110.8491.194.camel@balrog.2hip.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49CF283C.6050003>