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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 21 Jan 2016 08:58:49 +0100
From:	Daniel Vetter <daniel@...ll.ch>
To:	Michel Dänzer <michel@...nzer.net>
Cc:	Mario Kleiner <mario.kleiner.de@...il.com>,
	Vlastimil Babka <vbabka@...e.cz>,
	Ville Syrjälä 
	<ville.syrjala@...ux.intel.com>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	LKML <linux-kernel@...r.kernel.org>,
	dri-devel@...ts.freedesktop.org, mgraesslin@....org, kwin@....org,
	Alex Deucher <alexander.deucher@....com>,
	Christian König <christian.koenig@....com>
Subject: Re: linux-4.4 bisected: kwin5 stuck on kde5 loading screen with
 radeon

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