Re: linux-4.4 bisected: kwin5 stuck on kde5 loading screen with radeon

[Daniel Vetter]

On Thu, Jan 21, 2016 at 03:41:27PM +0900, Michel Dänzer wrote:
> On 21.01.2016 15:38, Michel Dänzer wrote:
> > On 21.01.2016 14:31, Mario Kleiner wrote:
> >> On 01/21/2016 04:43 AM, Michel Dänzer wrote:
> >>> On 21.01.2016 05:32, Mario Kleiner wrote:
> >>>>
> >>>> So the problem is that AMDs hardware frame counters reset to
> >>>> zero during a modeset. The old DRM code dealt with drivers doing that by
> >>>> keeping vblank irqs enabled during modesets and incrementing vblank
> >>>> count by one during each vblank irq, i think that's what
> >>>> drm_vblank_pre_modeset() and drm_vblank_post_modeset() were meant for.
> >>>
> >>> Right, looks like there's been a regression breaking this. I suspect the
> >>> problem is that vblank->last isn't getting updated from
> >>> drm_vblank_post_modeset. Not sure which change broke that though, or how
> >>> to fix it. Ville?
> >>>
> >>
> >> The whole logic has changed and the software counter updates are now
> >> driven all the time by the hw counter.
> >>
> >>>
> >>> BTW, I'm seeing a similar issue with drm_vblank_on/off as well, which
> >>> exposed the bug fixed by 209e4dbc ("drm/vblank: Use u32 consistently for
> >>> vblank counters"). I've been meaning to track that down since then; one
> >>> of these days hopefully, but if anybody has any ideas offhand...
> >>
> >> I spent the last few hours reading through the drm and radeon code and i
> >> think what should probably work is to replace the
> >> drm_vblank_pre/post_modeset calls in radeon/amdgpu by drm_vblank_off/on
> >> calls. These are apparently meant for drivers whose hw counters reset
> >> during modeset, [...]
> > 
> > ... just like drm_vblank_pre/post_modeset. That those were broken is a
> > regression which needs to be fixed anyway. I don't think switching to
> > drm_vblank_on/off is suitable for stable trees.
> 
> Even more so since as I mentioned, there is (has been since at least
> about half a year ago) a counter jumping bug with drm_vblank_on/off as well.

Hm, never noticed you reported that. I thought the reason for not picking
up my drm_vblank_on/off patches was that there's a bug in amdgpu userspace
where it tried to use vblank waits on a disabled pipe?

Can you please point me at the vblank on/off jump bug please?

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch