So... You are complaining because you ask for vsync and you get vsync...

I think this is really a issue here..A frame maybe stuck for several seconds even several minutes and screen blocked.. The same video file can be played smoothly under a good xf86_video_intel. This issue is easy to reproduce, so I think you can try to reproduce it and see how it's going. :)

You didn't say that originally :)

If it sticks for several seconds, you should have hangcheck warnings - which is what should be unsticking it.

Created attachment 86710 [details]
dmesg log

Hmm, we will have to wait for that BUG to be resolved first - it should be fixed already in -nightly.

Nope, BUG fix isn't merged yet.

The offending kernel patches have been reverted, so this should be working again...

(In reply to comment #7)
> The offending kernel patches have been reverted, so this should be working
> again...

Yes, it works now.
-----------------------
Libdrm:	(master)libdrm-2.4.46-46-gddbbdb13d80ea7f60e6f71356a444995b905366b
Mesa:	(master)373f8670d1c670003674e1eaa7c1f0cd823a0431
Xserver:	(master)xorg-server-1.14.99.2-2-gccbe17b1c6da1ad9d08 
Xf86_video_intel:	(master)2.99.903-38-g7284e7f48b812948b40d67396214f 
Cairo:	(master)49366c5e9e7d5afd0daef4c53a41472e020145eb
Kernel:	(drm-intel-nightly) ee3204556365264795ea557685b353bd2a271ce7

Progress on ppgtt patches is a bit on hold, so let's close this for now.

Verified.

Hi, it’s wrong for me to verify the bug. 
Last time I tested IVB and it’s OK, but the problem can’t reproduce on IVB.
The bug still exists on HSW and BYT-M, please see Xorg.0.log,dmesg.log and i915_error_state.log on HSW.
------------------------------------
Libdrm:	(master)libdrm-2.4.46-46-gddbbdb13d80ea7f60e6f71356a444995b905366b
Mesa:	(master)1176a3aac65dfe935809182bfac883708def8046
Xf86_video_intel:(master)2.99.903-47-g082c08789cf9a8c0cc2bf44d0fee579b96c0798f
Cairo:		(master)f1eefee985b4361386a167e80d9836593ade59b9
Libva:		(staging)f5c913765e6af38d835cacf339054ccc60bddefb
Kernel:	(drm-intel-nightly) git-4e1044

Created attachment 87369 [details]
dmesg.log

Created attachment 87370 [details]
i915_error_state.log

Created attachment 87371 [details]
Xorg.0.log

There's a test-case in xf86-video-intel/tests/dri2-test to exercise swaps (flips and vblank waits) on each connector. Can you please test this on your system and see if that reproduces the hang?

(In reply to comment #15)
> There's a test-case in xf86-video-intel/tests/dri2-test to exercise swaps
> (flips and vblank waits) on each connector. Can you please test this on your
> system and see if that reproduces the hang?

No, it's no hang. BYT, dri2-test runs in blank screen，dmesg:
------
[   44.428953] ALSA sound/pci/hda/hda_eld.c:334 HDMI: ELD buf size is 0, force 128
[   44.428987] ALSA sound/pci/hda/hda_eld.c:351 HDMI: invalid ELD data byte 0
[   44.429074] ALSA sound/pci/hda/hda_eld.c:334 HDMI: ELD buf size is 0, force 128
[   44.429116] ALSA sound/pci/hda/hda_eld.c:351 HDMI: invalid ELD data byte 0
[   47.149407] ALSA sound/pci/hda/hda_eld.c:334 HDMI: ELD buf size is 0, force 128
[   47.149442] ALSA sound/pci/hda/hda_eld.c:351 HDMI: invalid ELD data byte 0
[   47.149499] ALSA sound/pci/hda/hda_eld.c:334 HDMI: ELD buf size is 0, force 128
[   47.149531] ALSA sound/pci/hda/hda_eld.c:351 HDMI: invalid ELD data byte 0
[   49.769930] ALSA sound/pci/hda/hda_eld.c:334 HDMI: ELD buf size is 0, force 128
[   49.769944] ALSA sound/pci/hda/hda_eld.c:351 HDMI: invalid ELD data byte 0
[   49.769990] ALSA sound/pci/hda/hda_eld.c:334 HDMI: ELD buf size is 0, force 128
[   49.770012] ALSA sound/pci/hda/hda_eld.c:351 HDMI: invalid ELD data byte 0

And let's test hsw as well. If that also passes, please retest with mplayer (and update any error logs).

(In reply to comment #17)
> And let's test hsw as well. If that also passes, please retest with mplayer
> (and update any error logs).

Hi, #16 test based on HSW, "BYT" is typo:(  On HSW, mplayer still hang.

On BYT-M, call trace in dmesg attached when run dri2-test.

Created attachment 87446 [details]
call trace on BYT-M when run dri2-test

It only flips between two black windows, all that we care about is whether or not it generates an IO error or a GPU hang. Neither of which appear to be the case, so it looks to have passed.

Can you please test mplayer on all suspect machines (ivb/byt/hsw) and report whether any of those have a GPU hang (and only if they have a GPU hang)? All other warnings should be filed as a fresh bug report.

(In reply to comment #21)
> Can you please test mplayer on all suspect machines (ivb/byt/hsw) and report
> whether any of those have a GPU hang (and only if they have a GPU hang)? All
> other warnings should be filed as a fresh bug report.


GPU hang exists on BYT-M and HSW(desktop, mobile, ULT).BTW, I attached dmesg for HSW.
IVB is OK.

Created attachment 87783 [details]
HSW_dmesg.log

Found the Haswell bug,

commit 68cef6cd281572fcfb76a341dc45b7c8e5baffe6
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Nov 7 13:09:25 2013 +0000

    sna/gen7: Request secure batches for Haswell vsync
    
    Since commit 8ff8eb2b38dc705f5c86f524c1cd74a811a7b04c
    Author: Chris Wilson <chris@chris-wilson.co.uk>
    Date:   Mon Sep 9 16:23:04 2013 +0100
    
        sna/hsw: Scanline waits require both DERRMR and forcewake
    
    we have been emitting LRI to enable vsync on the render ring. This
    requires a privileged batch buffer, and whilst we were checking for
    kernel support, we forgot to actually tell the kernel to submit the
    batch with the right privileges.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71328
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

The baytrail symptoms are very similar (the LRIs are not landing) but the hardware implementation is completely difference (and the software doesn't have the same bug as haswell unfortunately.)

(In reply to comment #24)
Yes, it was fixed on HSW with above commit git-68cef6cd28.

This bug looks critical for me. 

Chris, do you agree this a high priority bug for you?

(In reply to comment #26)
> This bug looks critical for me. 
> 
> Chris, do you agree this a high priority bug for you?

It is, the only answer I have found so far has been to turn off vsync for byt. I have found no explanation as to why LRI seem not to work.

This goes against everything the render bspec says, but it doesn't ap[ear to hang:


diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c
index 8982d6a..c31a501 100644
--- a/src/sna/sna_display.c
+++ b/src/sna/sna_display.c
@@ -3923,6 +3923,8 @@ sna_wait_for_scanline(struct sna *sna,
                ret = false;
        else if (sna->kgem.gen >= 075)
                ret = sna_emit_wait_for_scanline_hsw(sna, crtc, pipe, y1, y2, full_height);
+       else if (sna->kgem.gen == 071)
+               ret = sna_emit_wait_for_scanline_gen4(sna, crtc, pipe, y1, y2, full_height);
        else if (sna->kgem.gen >= 070)
                ret = sna_emit_wait_for_scanline_ivb(sna, crtc, pipe, y1, y2, full_height);
        else if (sna->kgem.gen >= 060)

But though it doesn't hang, it is not sync'ed to vrefresh either.

Replacing the LOAD_SCANLINE_INCL with a LRI to 0x70004 is also ineffective. (No hang, still tears.)

(In reply to comment #28)
Yes, with above xf86 patch, the bug was fixed.

Haven't been able to resolve how to make vsync work on Baytrail, so applied

commit bd22abee8f33b20ff6bc7297b0a9ae8708d18727
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Nov 7 22:27:50 2013 +0000

    sna: Update Baytrail VSync logic
    
    My current best guess at the glaring hole in the spec that is
    synchronisation to vertical refresh.
    
    Note that this leaves VSync disabled for BYT for now as it is
    ineffective - but at least it now doesn't hang!
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69869
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

to prevent the hangs. Downgrading priority.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/issues/25.