From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752707AbcAVPSn (ORCPT ); Fri, 22 Jan 2016 10:18:43 -0500 Received: from mga02.intel.com ([134.134.136.20]:15387 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750944AbcAVPSk (ORCPT ); Fri, 22 Jan 2016 10:18:40 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,331,1449561600"; d="scan'208";a="866236376" Date: Fri, 22 Jan 2016 17:18:35 +0200 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Michel =?iso-8859-1?Q?D=E4nzer?= Cc: Mario Kleiner , Vlastimil Babka , LKML , dri-devel@lists.freedesktop.org, Alex Deucher , Christian =?iso-8859-1?Q?K=F6nig?= Subject: Re: linux-4.4 bisected: kwin5 stuck on kde5 loading screen with radeon Message-ID: <20160122151835.GM23290@intel.com> References: <569CC357.8030302@suse.cz> <569FEEDE.4060409@gmail.com> <56A053CE.7000500@daenzer.net> <56A06D2E.4000008@gmail.com> <56A07CF9.5060506@daenzer.net> <56A07D97.6030606@daenzer.net> <20160121075849.GH19130@phenom.ffwll.local> <56A0989E.30006@daenzer.net> <20160121100905.GL19130@phenom.ffwll.local> <56A19C98.8020208@daenzer.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <56A19C98.8020208@daenzer.net> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 22, 2016 at 12:06:00PM +0900, Michel Dänzer wrote: > > [ Trimming KDE folks from Cc ] > > On 21.01.2016 19:09, Daniel Vetter wrote: > > On Thu, Jan 21, 2016 at 05:36:46PM +0900, Michel Dänzer wrote: > >> On 21.01.2016 16:58, Daniel Vetter wrote: > >>> > >>> Can you please point me at the vblank on/off jump bug please? > >> > >> AFAIR I originally reported it in response to > >> http://lists.freedesktop.org/archives/dri-devel/2015-August/087841.html > >> , but I can't find that in the archives, so maybe that was just on IRC. > >> See > >> http://lists.freedesktop.org/archives/dri-devel/2016-January/099122.html > >> . Basically, I ran into the bug fixed by your patch because the counter > >> jumped forward on every DPMS off, so it hit the 32-bit boundary after > >> just a few days. > > > > Ok, so just uncovered the overflow bug. > > Not sure what you mean by "just", but to be clear: The drm_vblank_on/off > counter jumping bug (similar to the bug this thread is about), which > exposed the overflow bug, is still alive and kicking in 4.5. It seems > to happen when turning off the CRTC: > > [drm:drm_update_vblank_count] updating vblank count on crtc 0: current=218104694, diff=0, hw=916 hw_last=916 > [drm:radeon_get_vblank_counter_kms] crtc 0: dist from vblank start 3 > [drm:drm_calc_vbltimestamp_from_scanoutpos] crtc 0 : v 0x7 p(2199,-45)@ 7304.307354 -> 7304.308006 [e 0 us, 0 rep] > [drm:radeon_get_vblank_counter_kms] crtc 0: dist from vblank start 3 > [drm:drm_update_vblank_count] updating vblank count on crtc 0: current=218104694, diff=16776301, hw=1 hw_last=916 Not sure what bug we're talking about here, but here the hw counter clearly jumps backwards. > [drm:radeon_get_vblank_counter_kms] Query failed! stat 3 > [drm:radeon_get_vblank_counter_kms] Query failed! stat 3 > [drm:drm_update_vblank_count] updating vblank count on crtc 1: current=0, diff=0, hw=0 hw_last=0 > [drm:radeon_get_vblank_counter_kms] Query failed! stat 3 > [drm:radeon_get_vblank_counter_kms] Query failed! stat 3 > [drm:drm_update_vblank_count] updating vblank count on crtc 2: current=0, diff=0, hw=0 hw_last=0 > [drm:radeon_get_vblank_counter_kms] Query failed! stat 3 > [drm:radeon_get_vblank_counter_kms] Query failed! stat 3 > [drm:drm_update_vblank_count] updating vblank count on crtc 3: current=0, diff=0, hw=0 hw_last=0 > [drm:radeon_get_vblank_counter_kms] Query failed! stat 1 > [drm:drm_calc_vbltimestamp_from_scanoutpos] crtc 0 : v 0x1 p(0,0)@ 7304.317140 -> 7304.317140 [e 0 us, 0 rep] > [drm:radeon_get_vblank_counter_kms] Query failed! stat 1 > [drm:drm_update_vblank_count] updating vblank count on crtc 0: current=234880995, diff=16777215, hw=0 hw_last=1 Same here. These things just don't happen on i915 because drm_vblank_off() and drm_vblank_on() are always called around the times when the hw counter might get reset. Or at least that's how it should be. > dev->max_vblank_count = 0xffffffff, which makes the wraparound code in > drm_update_vblank_count a no-op. Maybe you can reproduce it if you > artificially set a lower max_vblank_count in the driver. > > > -- > Earthling Michel Dänzer | http://www.amd.com > Libre software enthusiast | Mesa and X developer -- Ville Syrjälä Intel OTC