On Tue, May 10, 2016 at 08:19:50PM +0300, Ville Syrjälä wrote: > On Tue, May 10, 2016 at 08:03:47PM +0300, Marius Vlad wrote: > > Robert Foss improved test/kms_vblank and in the same time extended it on > > all outputs and all pipes. The following seems to happen on pipe B (on > > pipe A the test always works): > > > > [46795.932490] [drm:drm_wait_vblank] returning 66 to client > > [46795.932509] [drm:drm_ioctl] pid=17715, dev=0xe200, auth=1, > > DRM_IOCTL_WAIT_VBLANK > > [46795.932512] [drm:drm_queue_vblank_event] event on vblank count 132, > > current 66, crtc 1
That 132 was already confusing me, so I started to look the full log. I then noticed the following pattern: [46795.882483] [drm:drm_queue_vblank_event] event on vblank count 129, current 63, crtc 1 [46795.899180] [drm:drm_queue_vblank_event] event on vblank count 130, current 64, crtc 1 [46795.915843] [drm:drm_queue_vblank_event] event on vblank count 131, current 65, crtc 1 [46795.932512] [drm:drm_queue_vblank_event] event on vblank count 132, current 66, crtc 1 So the target vblank count was incrementing in lockstep with the current counter value, which then told me these are relative waits instead of absolute as they should have been. It's a bug in the pipe_id_to_vbl_flag(). I replied to the relevant mail already. -- Ville Syrjälä Intel OTC _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
