still problems with intel video

[Lawrence Stewart]

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 at 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