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