Glitch in newer drm-next/drm-radeon-testing

[Marius Gröger]

Am Fri, 4 Jun 2010 11:17:12 -0400
schrieb Alex Deucher <alexdeucher at gmail.com>:

> 2010/6/4 Marius Gröger <marius.groeger at googlemail.com>:
> > Alex Deucher schrieb:
> >> 2010/6/4 Marius Gröger <marius.groeger at googlemail.com>:
> >>> Hi All,
> >>>
> >>> Michel Dänzer schrieb:
> >>>> On Mit, 2010-06-02 at 08:07 +0200, Marius Gröger wrote:
> >>>>> Hello All,
> >>>>>
> >>>>> I'm trying the top-of-trunk drm-2.6 trees (both drm-next and
> >>>>> drm-radeon-testing) with my Radeon HD 3200 GPU over HDMI. The
> >>>>> primary application is mythtv which uses DRM syncing for the
> >>>>> frame syncronisation. Now, with the exact same userland
> >>>>> software I noticed the introduction of sync gliches in the
> >>>>> May-timeframe. The drm-radeon-testing on May 9 was still ok,
> >>>>> but both drm-next and drm-radeon-testing at the end of May
> >>>>> showed that glitch: every couple of seconds there's a very
> >>>>> visual hickup, especially in scroll texts.
> >>>>>
> >>>>> Apologies for such an unspecific description, and for what
> >>>>> almost seems like a support request for MythTV. I wouldn't post
> >>>>> here if I were not 100% sure it must be related with the recent
> >>>>> drm changes.
> >>>> Note that the DRM APIs are intended for use by userspace
> >>>> components of graphics drivers / API libraries, not applications
> >>>> directly. MythTV shouldn't use the DRM directly for
> >>>> synchronization but rather use GLX synchronization APIs.
> >>> What about that new dri2 vsync stuff which was mentioned related
> >>> to [Bug 28383]? Could the changes done for that in any way alter
> >>> the timing? BTW I measured the glitches I'm experiencing and the
> >>> appear to be to happen in intervals of 10 seconds. Again, all I'm
> >>> changing is the kernel, and even the kernel config is the same.
> >>> I'd be most grateful for any clues/hints/tips I could follow to
> >>> resolve this regression.
> >>>
> >>>> If you have dynamic PM enabled, does disabling that help?
> >>> I checked again and there's method=profile and profile=default.
> >>> Afaict this is not using dynpm, right?
> >>>
> >>
> >> Correct.
> >
> > Ok so with dynpm more or less ruled out, what could have such a
> > visible impact on the latencies? For instance, are we now more
> > dependent (or less) on some kind of interrupt or deferred
> > processing than 6 weeks ago?
> >
> > Btw, I have HDMI audio pretty much ruled out as well.
> 
> Any chance you can bisect the problematic commit?

As I said, I already tried bisecting but failed. Perhaps I can try
again and replay at least part of the log... But since we're talking
about more than 120 commits I kinda was hoping to get some clues here
first. Even with a tailored .config building/rebooting/testing takes
ages. Well I suppose I needn't tell *you* guys... ;-)

Thanks
Marius