Re: [PATCH] drm/i915,agp/intel: Do not clear stolen entries

[Chris Wilson]

> On Jan 30, 2011, at 1:28 AM, Hugh Dickins wrote:
> > I just tried setting the debug to 7 for a few seconds on 2.6.37, where
> > I see no problem: I appear to get the "pipe a underrun" messages with
> > that too; and the drm_ioctl messages, but much much fewer of them.
> > Though I've been veering between i386 and x86_64 in these tests, so
> > keep that in mind if what I'm saying makes no sense: the huge number
> > of drm_ioctls was with 2.6.36-rc2 (plus some of Chris's fixes) on
> > i386; the 64 underruns per second was with 2.6.36-rc2 (plus some of

There shouldn't be any difference between the drm_ioctl() calls between
2.6.37 and 2.6.38 as the userspace is the same. I think this might the
crux of the issue. Can you attach a drm.debug=0xe boot dmesg, and a sample
of drm.debug=0x7 during the busy period for .37 and .38? And also your
Xorg.0.log.

Running fvwm and a couple of xterms you should not be utilizing vblanks at
all (not even suffering the vblank interrupt being enabled) so this code
should not even be causing unwanted side-effects. Bizarre.

The delay in characters showing up is a bug in the ddx; the render queue
is not being flushed before X goes to sleep. It's either the batch not
being submitted or the render cache not being flushed to the scan out in a
timely manner. (And these bugs can be complicated further by the
introduction of a compositing WM.) Both bugs have existed off-and-on in
the ddx over the years. And over time, we have weaned the kernel from
flushing the graphics caches unnecessarily; though the larger impact would
have been during the .37 cycle, at least the ones that sprang to mind as
likely candidates.

The pipe-a underrun is a nuisance; at best nothing will happen, there's an
outside chance that your display may flicker and at worst your machine may
hard hang.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/