Re: drm on i965GM is very sluggish

On Sat, 2009-03-21 at 20:57 -0700, Steve Kargl wrote:
> On Sat, Mar 21, 2009 at 10:38:59PM -0500, Robert Noland wrote:
> > On Sat, 2009-03-21 at 20:27 -0700, Steve Kargl wrote:
> > > On Sat, Mar 21, 2009 at 10:09:20PM -0500, Robert Noland wrote:
> > > > On Sat, 2009-03-21 at 19:47 -0700, Steve Kargl wrote:
> > > > > 
> > > > > I also just noticed that dmesg had
> > > > > 
> > > > > drm0: <Intel i965GM> on vgapci0
> > > > > info: [drm] MSI enabled 1 message(s)
> > > > > 
> > > > > Is it possible to disable MSI and still run drm?
> > > > 
> > > > Yes, There is a tuneable hw.drm.msi
> > > > 
> > > > I did do all of the msi development on a 965gm.  Unfortunately, I no
> > > > longer have access to that hardware.
> > > > 
> > > > Do you have witness enabled?
> > > > 
> > > 
> > > Yes.  And invariants.
> > 
> > Ok, and it isn't screaming that I did something bad?  Mostly this is
> > just a sync to what Intel is shipping... I did replace my irq handler
> > with anholt's, but they were pretty close.
> > 
> 
> Neither witness nor invariant appear unhappy.  The only think I see
> in /var/log/messages is 
> 
> Mar 21 19:30:33 REMOVE kernel: error: [drm:pid22190:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0

I thought that I fixed this... I guess not.  On the 965gm's LVDS is on
pipe 1, so if your using a laptop with only the built in display, pipe 1
is active and pipe 0 is not.  Something is being brain damaged and
asking for vblank on both pipes or the wrong pipe.  Are you seeing it
only on vt switch, or in the logs while things are running?  It should
be harmless, at one point I had converted it to a debug message, but it
slipped back in as an error.

> IIRC, you said this can be ignored.
> 
> I'll try disabling MSI later tonight.

There is a hardware errata on the 965gm regarding msi.  Intel had huge
trouble when they tried enabling it, but I could never produce the
issue.  They disabled msi for a while, but were still having problems.
Then Eric reworked the irq handler much like mine and they re-enabled
it.  I ran that way on my 965 for quite a while before I pushed that
code into the tree.

It looks like what is happening is that user interrupts which Intel uses
as markers in the command stream, are getting lost.  Then it stuck
waiting on things to catch up.  I'm betting that if you enable drm
debugging you will see several ioctl interrupted or restarting ioctl
messages.

I'm really frustrated with interrupts on Intel... You would think they
could get this right.

robert.

-- 
Robert Noland <rnoland_at_FreeBSD.org>
FreeBSD