Hello, I'm currently experiencing an issue where my two display port driven screens flicker randomly. At first I thought this was a kernel driver issue but as the kernel modules have progress I'm thinking less so. I'm currently working through a FIFI underrun here: https://bugs.freedesktop.org/show_bug.cgi?id=70254 However I've noticed that my screen blanks no longer accurately correlate with the "[drm:ilk_display_irq_handler], Pipe X FIFO underrun" logs that are being spit out. I can have many screen flickers but nothing is output in the logs, which leads be to believe the error is somewhere higher in the stack. My hardware is a lenovo X220 with a sandybridge era i7. # uname -a Linux rnavarro-thinkpad 3.13.0-994-generic #201401210405 SMP Tue Jan 21 09:05:52 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux I'm currently running on ubuntu 13.10 with the latest 3.13 mainline kernel and packages from the xorg-edgers PPA which includes xserver-xorg-video-intel at "2:2.99.907+git20140117.f23ab963-0ubuntu0sarvatt~saucy" I'm attaching a few logs, but any assistance in helping me track down this flicker would be great! Let me know what other information is required.
Created attachment 92604 [details] xrandr --verbose
Created attachment 92606 [details] Xorg log
Created attachment 92608 [details] dmesg
The higher levels of flicker involve displaying the backbuffer instead of the frontbuffer - so you either see stale rendering or partially re-rendered state. Flickering due to underrun tends to be much more regular in its content, the screen either wholly (or more usually partially) flickers to black (or another colour), or sometimes part of the screen changes colour. Sometimes this is associated with the position of the cursor (since that too is using display/memory bandwidth concurrently with the primary display plane). Is there any chance you can record the flicker using a phone? Also if the flicker shows up in a screencast (i.e. when recording the frontbuffer of the display) that implies that the error is at an even higher level of the stack.
(In reply to comment #4) > Flickering due to underrun tends to be much more regular in its > content, the screen either wholly (or more usually partially) flickers to > black (or another colour), or sometimes part of the screen changes colour. A single pane goes entirely black for a few seconds then comes back on. I don't see any discoloration or tearing or any other visual artifacts. > Sometimes this is associated with the position of the cursor (since that too > is using display/memory bandwidth concurrently with the primary display > plane). I'll watch for any correlation between pointer and screens > Is there any chance you can record the flicker using a phone? I'll see what I can do to get this for you. > if the flicker shows up in a screencast (i.e. when recording the frontbuffer > of the display) that implies that the error is at an even higher level of > the stack. Any screencast apps that you recommend I try? Or just anything?
(In reply to comment #5) > (In reply to comment #4) > > Flickering due to underrun tends to be much more regular in its > > content, the screen either wholly (or more usually partially) flickers to > > black (or another colour), or sometimes part of the screen changes colour. > A single pane goes entirely black for a few seconds then comes back on. I > don't see any discoloration or tearing or any other visual artifacts. Just one out of a pair? The ddx uses (in most circumstances anyway) a single fb for both and flips both at the same time. This observation leads me to think it is underruns... > > if the flicker shows up in a screencast (i.e. when recording the frontbuffer > > of the display) that implies that the error is at an even higher level of > > the stack. > Any screencast apps that you recommend I try? Or just anything? Any tool. All that we want to verify is that there is no corruption in the root image, so anything that uses XGetImage or DRI2 reads from the frontbuffer will be adequate.
(In reply to comment #6) > Just one out of a pair? The ddx uses (in most circumstances anyway) a single > fb for both and flips both at the same time. This observation leads me to > think it is underruns... The monitors are independent when they blank, here's a video: http://www.youtube.com/watch?v=7L5vZz-APUM > Any tool. All that we want to verify is that there is no corruption in the > root image, so anything that uses XGetImage or DRI2 reads from the > frontbuffer will be adequate. Here is the tool I used to test: http://recordmydesktop.sourceforge.net/about.php When recording the video the right monitor blanks, but the recording does not. Which suggests to me that it is a an underrun issue as you described. http://www.youtube.com/watch?v=hftue_XLusU
I feel a bit more confident now in saying that this is likely to be just underruns :)
Hey Chris, Thanks for the followup. I'll get things fixed up in the other case (waiting for the code to get pushed out) and I'll report back.
Presuming this is fixed with the snb watermark latency fix. Please reopen if that's no the case.
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.