Created attachment 88168 [details] entire Xorg.0.log I just upgraded to the intel driver in version 2.99.905 in order to try the improved TearFree option. It seems to work fine (yay, thanks!), but a couple minutes later my display just turned off. Switching to vt1 and back to vt7 was enough to get it back on, but I suspect this will happen more often, so I figured I’d report it. The last few lines in /var/log/Xorg.0.log are: [2450513.409] (II) intel(0): switch to mode 2560x1440@60.0 on pipe 0 using DP2, position (0, 0), rotation normal [2451327.200] (EE) intel(0): sna_mode_redisplay: page flipping failed, disabling CRTC:3 (pipe=0) [2451340.647] (II) AIGLX: Suspending AIGLX clients for VT switch [2451346.532] (II) Open ACPI successful (/var/run/acpid.socket) [2451346.532] (II) AIGLX: Resuming AIGLX clients after VT switch [2451346.532] (II) intel(0): switch to mode 2560x1440@60.0 on pipe 0 using DP2, position (0, 0), rotation normal Full Xorg.0.log attached. Please let me know if you need any other information. I am using the integrated GPU of the following processor: cpu family : 6 model : 42 model name : Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz stepping : 7
This should prevent the display turning off after the odd failure: commit 4e0a01a7a3cf0f473c7ffae9129069086bf2fbe2 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sun Oct 27 15:33:13 2013 +0000 sna: Handle transient TearFree flip failures If we get a pageflip fail when trying to do a TearFree update, just fallback to a copy (before turning off the display for complete failure). The rare tearing copy should mar the user experience far less. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
I believe the workaround should be effective and hide the issue.
(In reply to comment #2) > I believe the workaround should be effective and hide the issue. Thanks for the quick fix! I only now had a chance to upgrade my version of the driver, and so far I haven’t had the issue. Will report back in the unlikely event that it still happens.
Created attachment 88930 [details] (new) entire xorg.log
(In reply to comment #3) > (In reply to comment #2) > > I believe the workaround should be effective and hide the issue. > Thanks for the quick fix! I only now had a chance to upgrade my version of > the driver, and so far I haven’t had the issue. Will report back in the > unlikely event that it still happens. It just happened again: [3146197.461] (EE) intel(0): sna_mode_redisplay: page flipping failed, disabling CRTC:3 (pipe=0) [3146199.888] (II) AIGLX: Suspending AIGLX clients for VT switch [3146200.700] (II) Open ACPI successful (/var/run/acpid.socket) [3146200.700] (II) AIGLX: Resuming AIGLX clients after VT switch [3146200.700] (II) intel(0): switch to mode 2560x1440@60.0 on pipe 0 using DP2, position (0, 0), rotation normal [3146201.213] setversion 1.4 failed This is with commit abf1a16914d993cc150005879375d4bb17fdccf3. New full Xorg.0.log attached.
That's quite an old version of xf86-video-intel: 2.21.15. Certainly doesn't contain the recent fix.
(In reply to comment #6) > That's quite an old version of xf86-video-intel: 2.21.15. Certainly doesn't > contain the recent fix. I built it from git. The commit ID I gave you was accurate. Ignore the version it reports, I build it as a Debian package without updating the version number.
Ah, this looks to be a different class of fail. Do you have the dmesg for that run? Could you reproduce this with drm.debug=6 (or echo 6 > /sys/modules/drm/parameters/debug) and grab the dmesg?
(In reply to comment #8) > Ah, this looks to be a different class of fail. Do you have the dmesg for > that run? Could you reproduce this with drm.debug=6 (or echo 6 > > /sys/modules/drm/parameters/debug) and grab the dmesg? I looked into /var/log/syslog, but don’t see any dmsg output for that time period. I can try to reproduce it, but not before the weekend.
Created attachment 89295 [details] Xorg.0.log
Created attachment 89297 [details] dmesg with drm.debug=6
Working on xf86-video-intel-2.21.15 here, also experiencing screen blackouts. I've attached my Xorg.log and dmesg after switching drm.debug=6. I will try to build newer drivers and test them tomorrow. Triggering the bug is easy for me, using gMaps in a fullscreen browser window.
Created attachment 89313 [details] dmesg with drm.debug=6 from current drivers Updated to current from git. No error shows up in Xorg.log now, the blackout sill occurs. During boot up, there is [drm:intel_pipe_config_compare] *ERROR* mismatch in gmch_pfit.lvds_border_bits (expected 32768, found 0) I'm not sure now if it's the same issue.
I'm now working on last tagged version from git - 2.99.906. Seems a little more stable than .905, at least on desktop G45. On mobile GM45 I have some strange flickering with old frames showing. On both machines still some occasional xorg crushes. So no TearFree for me. I was only testing it because of tearing while decoding with vaapi/intel-driver g45-h264 branch so I'm still impressed.
A couple more bugs with TearFree were fixed, but I'm interested in getting a --enable-debug=full Xorg.0.log that ends with the page flip fail.
*** Bug 71585 has been marked as a duplicate of this bug. ***
Chris, I am able to reproduce this faithfully by enabling TearFree, launching the Spotify application, and searching for something in Spotify. Almost immediately (after I see some changes in Spotify's window), the screen blanks, and I then see text from the console run of startx. The console is hung at that point. I pulled the latest git and compiled with --enable-debug=full. The Xorg.0.log is too large for bugzilla, so here's the link: http://data.boulder.swri.edu/~joe/Xorg.0.log Let me know after you have grabbed this so I can remove it - hope it's helpful.
Hmm, grabbed your Xorg.0.log, but I don't see the failure message and subsequent disabling of the output. Just to be sure, these are the last lines I have: [ 612.221] sna_pixmap_move_to_gpu(pixmap=4, usage=16), flags=a [ 612.221] wait_for_shadow: flags=a, shadow_flip=0, handle=31, wait=58, old=58 [ 612.221] sna_pixmap_move_to_gpu: already all-damaged [ 612.221] sna_pixmap_mark_active: pixmap=4, handle=31
(In reply to comment #18) Chris, true, it ends that way - not sure why, as it does blank/crash (maybe it did not have a chance to fully flush?). I will now build 2.99.907 with full debug and see if I can get it to produce a log file with the message - maybe that will help... stand by.
(In reply to comment #19) OK, Chris, I've done 4 more tests, using 2.99.907 and the latest git. All end up crashing, but I noticed that, like before, the full debug logs seem not to have the page flipping fail msg, whereas the no debug logs do. Also, when I make it crash with no debug, I get to a blank screen, and then I can go to another console and log back in. Whereas if full debug is enabled, I see blank, then the last screen from the console in which I ran startx, and I cannot go to another console (need to shut down and restart). Here are the files; let me know when you get them: http://data.boulder.swri.edu/~joe/Xorg.0.log_2.99.907_full_debug http://data.boulder.swri.edu/~joe/Xorg.0.log_2.99.907_no_debug http://data.boulder.swri.edu/~joe/Xorg.0.log_git_full_debug http://data.boulder.swri.edu/~joe/Xorg.1.log_git_no_debug Any clue as to why I am seeing this difference with full debug on? Let me know if I can try anything else.
(In reply to comment #20) > Any clue as to why I am seeing this difference with full debug on? Let me > know if I can try anything else. Full-debug will also turn on a number of assertions which it may then be tripping over. Unfortunately these are only reported on stderr. Do you have that captured to any logfile (e.g. xdm.log or gdm.log)?
Created attachment 92365 [details] stdout/stderr from startx during issue Chris, attached is the output from startx. Hope this is what you were referring to. It does show an assertion. I uploaded the associated/new Xorg.0.log to the same location as before: http://data.boulder.swri.edu/~joe/Xorg.0.log_git_full_debug
Ok, but I don't think that assert explains the pageflip failure though. :( This should fix the assert: diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c index 10ee9e4..000d9ab 100644 --- a/src/sna/sna_display.c +++ b/src/sna/sna_display.c @@ -4530,7 +4530,17 @@ void sna_mode_redisplay(struct sna *sna) return; } - assert(sna_pixmap(sna->front)->move_to_gpu == NULL); + { + struct sna_pixmap *priv; + + priv = sna_pixmap(sna->front); + assert(priv != NULL); + + if (priv->move_to_gpu) + (void)priv->move_to_gpu(sna, priv, 0); + + assert(priv->move_to_gpu == NULL); + } for (i = 0; i < config->num_crtc; i++) { xf86CrtcPtr crtc = config->crtc[i];
(In reply to comment #23) Is there a debug level or any other debug tooling I can use that will not trigger the asserts, but will give you more info on the failure? I can reproduce it instantly every time with my setup, so this is a good opportunity to find the problem if you can think of way I can get you more info.
I was trying to trigger page flip error with 2.99.907-31-gde0797e --enable-debug=full build with no effect. Tried Spotify client as Joe suggested (running in wine, right?), got X Server termination with: (EE) sna_copy_boxes: damage box is beyond the pixmap: box=(1, 1), (32, 33), pixmap=(32, 32) I thought it was different issue so just to be sure tried with TearFree disabled - gives me the same error. So is Xorg.log with current config and some lines before crush needed?
(In reply to comment #25) > I was trying to trigger page flip error with 2.99.907-31-gde0797e > --enable-debug=full build with no effect. Tried Spotify client as Joe > suggested (running in wine, right?), got X Server termination with: > > (EE) sna_copy_boxes: damage box is beyond the pixmap: box=(1, 1), (32, 33), > pixmap=(32, 32) Do you still have the Xorg.0.log? That's a different (and very unusual) bug that needs to be fixed.
Created attachment 92450 [details] Xorg.0.log --enable-debug-full damage box is beyond the pixmap Log with "damage box is beyond the pixmap", about 1000 lines from the top and down. I hope it's usefully cropped.
Thanks, that is most peculiar. For an inexplicable reason the clip-to-dst-clip didn't seem to be sufficient, so I added some more debug output. Then I noticed that it should be a fallback anyway, so provided a shorter fallback path (and hopefully beefed up the debugging to catch the error along that path as well). Long story short, please try to capture a fresh debug log with xf86-video-intel.git: commit 4c7b183fd21b461f9f18662c3b9d9732b6bef13d Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Jan 20 14:35:55 2014 +0000 sna: Short-cut the fallback for XCopyArea with depth < 8 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> commit 671658499bf432666a96b31ac96d2c66e2168c4c Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Jan 20 14:35:35 2014 +0000 sna: Add some more DBG output around the clipping in sna_do_copy() Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Created attachment 92469 [details] damage box is beyond the drawable 2.99.907-38-g4c7b183 About it being a different bug - I'm really new to bugzilla, should it be moved to a new bug report?
Interesting about the different problem triggered by Spotify. I still get the page flip issue using Spotify - could these two problems be related? I wish I could provide more meaningful debug info on my case...
(In reply to comment #29) > Created attachment 92469 [details] > damage box is beyond the drawable 2.99.907-38-g4c7b183 > > About it being a different bug - I'm really new to bugzilla, should it be > moved to a new bug report? Yes, I was hoping it would be trivial enough to fix immediately, but even then a separate bug is much better for tracking in changelogs and NEWS.
What's happening in this bug digression is that we miss recomputing the gc->pCompositeClip. Strange, very strange. Again, I have added some extra debugging to narrow down why, commit 50f6701aa5ce8be96e216a942880a8db967c7a6a Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Jan 20 20:47:15 2014 +0000 sna: Include serial numbers in ValidateGC DBG Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> and would appreciate it if you could gather another debug log for me. Thanks.
Ok, I believe xf86-video-intel.git has all the fixes for the assertions you have all hit, so we should be ready for another shot at getting the vital debug for the pageflipping failure. Any volunteers?
Chris, traveling today, so no time this AM, but I can try it either this evening or tomorrow...
Any one had a chance to run with full debug recently?
Chris, I put some log files here: http://data.boulder.swri.edu/~joe/ Xorg.0.log and Xorg.0.log3 both happened with TearFree on using the Spotify search test. I fear not much of use is in these, but please look (I looked at the tail of each). Xorg.0.log2 happened with TearFree off just going into Chromium - unusual. xorg_output.log3 accompanies Xorg.0.log3 as the stdout/stderr from startx during the session. Looks like another assertion.
(In reply to comment #36) > Chris, > > I put some log files here: > > http://data.boulder.swri.edu/~joe/ > > Xorg.0.log and Xorg.0.log3 both happened with TearFree on using the Spotify > search test. I fear not much of use is in these, but please look (I looked > at the tail of each). You underestimate the value of your debugging - it was very, very useful. Thank you. commit 4b73a0ea22b43807c0118f4d7e9dcac3f0626463 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Jan 29 05:32:25 2014 +0000 sna: Skip undamaged TearFree redisplays If we have not had cause to flush the wait_for_shadow buffer during the course of the rendering, then we never wrote to the backbuffer and its contents are still identical to the current frontbuffer. So if the wait_for_shadow is still flagged as required on the scanout, we know we can safely discard the redisplay request. References: https://bugs.freedesktop.org/show_bug.cgi?id=70905 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Time to try again! > Xorg.0.log2 happened with TearFree off just going into Chromium - unusual. Another assertion - not sure which, at a guess it decided the pointer was incoherent, which looks more like a bogus assertion...
(In reply to comment #37) > You underestimate the value of your debugging - it was very, very useful. > Thank you. Good to know! :) > Time to try again! OK, pulled git and rebuilt this morning... Good news, I think. New files are in the same place: http://data.boulder.swri.edu/~joe/ > > Xorg.0.log2 happened with TearFree off just going into Chromium - unusual. > > Another assertion - not sure which, at a guess it decided the pointer was > incoherent, which looks more like a bogus assertion... I tried a similar case (starting X and running Chromium with TearFree off). No crash (but maybe that assertion is hard to hit). Log files named with "_noTearFree_chromium". I tried the Spotify with TearFree case, and no crash there, either! Log files names with "_TearFree_spotify". I'll keep running with the debug version for a while with TearFree on. I wonder if this last round of changes did the trick - fingers crossed!
(In reply to comment #38) > (In reply to comment #37) > > You underestimate the value of your debugging - it was very, very useful. > > Thank you. > > Good to know! :) > > > Time to try again! > > OK, pulled git and rebuilt this morning... Good news, I think. New files > are in the same place: Heh, apparently '%D' is a typo that we need to be told about at 60Hz. > http://data.boulder.swri.edu/~joe/ > > > > Xorg.0.log2 happened with TearFree off just going into Chromium - unusual. > > > > Another assertion - not sure which, at a guess it decided the pointer was > > incoherent, which looks more like a bogus assertion... > > I tried a similar case (starting X and running Chromium with TearFree off). > No crash (but maybe that assertion is hard to hit). Log files named with > "_noTearFree_chromium". Had another bug report that revealed I screwed up in one of the patches yesterday which can explain all manner of strange failures. > I tried the Spotify with TearFree case, and no crash there, either! Log > files names with "_TearFree_spotify". > > I'll keep running with the debug version for a while with TearFree on. I > wonder if this last round of changes did the trick - fingers crossed! *fingers crossed* Certainly the issue in theory fixed by the patch this morning has the right hallmarks of being a random, hard to trigger bug that would end up not only causing the page-flip error but also the blit failure -- i.e. I think it explains this bug...
I think Joe's happy - anyone else have a pass/fail report for the latest ddx + TearFree?
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.