Messages in this thread | | | Date | Sun, 30 Jan 2011 09:55:34 +0000 | Subject | Re: [PATCH] drm/i915,agp/intel: Do not clear stolen entries | From | 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
| |