i915_tex driver locks X when starting compiz

[Michel Dänzer]

On Wed, 2007-08-15 at 12:08 +1000, Daniel Kasak wrote:
> On Tue, 2007-08-14 at 09:43 +0200, Michel Dänzer wrote:
> 
> > On Tue, 2007-08-14 at 11:45 +1000, Daniel Kasak wrote:
> > > 
> > > The legacy driver works as before, though the fastest method is
> > > still with XAA and XAANoOffscreenPixmaps set - I'm not sure of the
> > > zero-copy-tfp stuff is in the older driver ... is it?
> > 
> > Not yet, feel free to port it. :)
> 
> Trust me ... I would if I could. I've often thought that if I learned C,
> I'd be working on E17 and video card drivers. But this is probably
> waaaaay to optimistic of me. At the moment I have about 8 years of VB, 5
> years of PHP, and 3 years of Perl experience. I've had a couple of
> aborted attempts at one of the 'teach yourself C in 21 days' books -
> mainly due to time constraints and other programming projects ( eg
> http://entropy.homelinux.org/axis ). Is it feasible that I'd be able to
> quickly ( a couple of hundred hours ) learn enough C to do this porting
> job? Keep in mind I'd be basically starting from scratch again.

I agree with Colin that the language itself probably isn't as much of an
issue as the other concepts involved. Anyway, this was a call for anyone
else as much as for you specifically, so don't feel personally
responsible for this.


> > What about the X server stderr output?
> 
> Nothing that I don't recognise when EXA is in use. When I use XAA, I
> get:
> 
> X: symbol lookup error: /usr/lib/xorg/modules/drivers//i810_drv.so:
> undefined symbol: exaMoveInPixmap

That's a bug, it can't do zero-copy TFP with XAA. Dave Airlie fixed this
in GIT.

On the bright side, this confirms that you should basically be all set
for zero-copy TFP with EXA.


> > > Each time I tested, the screen went black and never returned, but the 
> > > cursor stayed visible and followed mouse movements. I couldn't switch 
> > > to another VT, but I could ssh in and reboot.
> > 
> > Hmm, sounds like a GPU lockup, though the X driver should detect that
> > and abort with some debugging output...
> 
> I've locked it up probably 30 times now over the past day or so, and
> each time I could ssh in and reboot it, but it never aborted with
> debugging info.

Hmm, then it could be some kind of deadlock somewhere.


> > It could be related to the DRM memory manager area being only 2048 KB;
> > if you can, try increasing the AGP aperture size in the BIOS setup.
> > Otherwise, try Option "AperTexSize" with values between the default
> > 32768 and 2048.
> 
> Right. This gave me another couple of dozen test cases, that brought out
> some strange things.
> 
> To start with, my AGP aperture size in the BIOS was at its largest:
> 256MB. But no matter what I set it to ( 256, 128, 64 ), I always get the
> same kernel message on bootup:
> 
> agpgart: Detected an Intel 845G Chipset.
> agpgart: Detected 892K stolen memory.
> agpgart: AGP aperture is 128M @ 0xe8000000
> 
> Also, I've told the BIOS to steal 8MB of system memory ( which is
> unfortunately the maximum ). I didn't try lowering it.

Stolen memory is useless for the DRM memory manager.

> Is there a problem with agpgart always detecting a 128MB aperture?

Yeah, looks like some issue between the BIOS and agpgart.


> In particular, I tested all AperTexSize settings for a 128MB Aperture
> ( since agpgart keeps insisting I've got this size ).
> 
> I did get slightly different behaviour with different combinations.
> Sometimes, the mouse pointer would also freeze / disappear. Sometimes
> the gnome background would appear. But each time I got a lockup anyway.

Did you check in each case whether it was actually using the specified
value or falling back to 2048? The idea is to find the largest value it
actually ends up using.


-- 
Earthling Michel Dänzer           |          http://tungstengraphics.com
Libre software enthusiast         |          Debian, X and DRI developer