From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754354AbcAWSYy (ORCPT ); Sat, 23 Jan 2016 13:24:54 -0500 Received: from mail-wm0-f52.google.com ([74.125.82.52]:33512 "EHLO mail-wm0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754045AbcAWSYC (ORCPT ); Sat, 23 Jan 2016 13:24:02 -0500 Subject: Re: linux-4.4 bisected: kwin5 stuck on kde5 loading screen with radeon To: =?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= , =?UTF-8?Q?Michel_D=c3=a4nzer?= 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> <20160122151835.GM23290@intel.com> <56A27508.4050701@gmail.com> Cc: Vlastimil Babka , LKML , dri-devel@lists.freedesktop.org, Alex Deucher , =?UTF-8?Q?Christian_K=c3=b6nig?= From: Mario Kleiner Message-ID: <56A3C53E.9010908@gmail.com> Date: Sat, 23 Jan 2016 19:23:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56A27508.4050701@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/22/2016 07:29 PM, Mario Kleiner wrote: > > > On 01/22/2016 04:18 PM, Ville Syrjälä wrote: >> 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. >> > > Fwiw, testing the HD-57570 single display with my patch that uses > drm_vblank_off/on() in the DPMS OFF/ON path of radeon-kms does show > hardware counter reset to zero as expected, but no jumps of software > vblank counter. So with that vblank_off/on placement it seems to work > nicely here. > > -mario > I spoke too early. The jump doesn't happen when i change video modes - video resolution / refresh rate etc, despite hw counter reset. But if i just disable and then reenable a display, the software counter jumps. -mario