Intel GPU kernel driver

[Kostik Belousov]

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 screen
> >>>>(https://lh4.googleusercontent.com/-WmDhn1X-Ze0/Thn-O5dfeiI/AAAAAAAAABM/WIX3co3DQaM/s720/20110710_003-1.jpeg)
> >>>>though 9-th (occupied by X) is always displayed properly;
> >Yes, VT switch handling is not implemented.
> 
> Okay, got it (just expressed my observations)
> 
> >>Also not sure that X actually operates w/o acceleration: the following
> >>output makes me think so:
> >>
> >># env LIBGL_DEBUG=verbose sh -c 'glxinfo 2>&1' | egrep '(render|Driver)'
> >>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.
> 
> Yeap, agree. Unfortunately I hadn't appropriate apps at my hand at that 
> very moment. Though freaking artificial glxgears ran w/o issues (sorry 
> for my ignorance... I'm not a fan of games, GL neat features/effects and 
> stuff like that, so if you can recommend smth. to test it thoroughly 
> I'll do it and report the results)
Working glxgears with direct rendering reported 'on' is enough to
make sure.

> 
> >>
> >>Additional information:
> >>- pciconf -lvb: http://pastebin.com/YT8wUBiZ
> >So this is another Ironlake.
> 
> Hm... not sure if I got this properly. In the first post I mentioned 
> that there is a laptop "with integrated Intel graphics card (Ironlake, 
> 0x00468086)". pciconf -lvb output also reports "chip=0x00468086". AFAIK 
> there are two types of chips: 0x00428086 (a.k.a. "D" (desktop?)) and 
> 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.

> 
> >>
> >>- 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.
> 
> yeap, the second dmesg's output (failsafe) is clean and mentioned just 
> for comparison. However the first one (http://pastebin.com/DU3RvzTi) 
> contains suspicious entries (for instance line #333, #340, #367 and so 
> forth). So I thought it could be helpful (though you considered it 
> 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.
> 
> >>
> >>- and just in case X logs (with ModeDebug="true"):
> >>http://pastebin.com/iEPxm8ib
> >When did the X server segfaulted ?
> 
> X segfaulted on attempt to enable desktop effects (presumes usage of 
> composite extension). Both aforementioned logs (Xorg.log 
> (http://pastebin.com/iEPxm8ib) and first dmesg output 
> (http://pastebin.com/DU3RvzTi) were collected within 2-5 seconds right 
> after X segfaulted.
> 
> Also, forgot to mention that hw.dri.0.info.i915_error_state didn't 
> contain any errors.

This makes me almost certain that the issue is in userland.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20110712/ed2d5b5a/attachment.pgp