Bug 70254

Created attachment 87257 [details]
glxinfo output

Forgot to mention, let me know if there is any other information that you need or if you'd like me to change any settings to up the debug level anywhere (along with location)

You've come to the right place - if you're prepared to build your own kernels. Please try the drm-intel-nightly branch of [1]. First, your issues are related to hotplugging and display port link training/maintenance, both of which have been updated and fixed considerably in the latest kernels. It could be something we've taken care of already. Second, I can't find a kernel version where your log would match the source code; I can only presume it's a distro kernel with some changes on top. So I don't know what exactly you're running and what version I should be looking at.

Please report back; if the problem persist, attach the dmesg from early boot to the problem, with drm.debug=0xe module parameter.

[1] git://people.freedesktop.org/~danvet/drm-intel

Hello Jani,

So I've gone ahead and updated my os install to the latest ubuntu, bringing me up to the 3.11.0-12 kernel.

It looks like the hot plug issues have gone away, which is great....however once I turned on debugging like you mentioned I figured out what was actually going on.

Right before my either of my monitors goes blank I get a message emitted like this:

Oct 12 11:22:02 rnavarro-thinkpad kernel: [  673.201706] [drm:ironlake_irq_handler], Pipe B FIFO underrun
Oct 12 11:22:02 rnavarro-thinkpad kernel: [  673.201719] [drm:cpt_serr_int_handler], PCH transcoder B FIFO underrun

Shortly after my second monitor goes blank, emitting a similar message:
Oct 12 11:22:31 rnavarro-thinkpad kernel: [  702.411812] [drm:ironlake_irq_handler], Pipe A FIFO underrun

Is there more detailed debug information that I can output to help identify what is causing this?

I'm driving both monitors with:
Oct 12 11:22:56 rnavarro-thinkpad kernel: [  727.212145] [drm:drm_mode_debug_printmodeline], Modeline 32:"2560x1440" 60 241500 2560 2608 2640 2720 1440 1443 1448 1481 0x48 0x9

Updating subject accordingly. We probably have fixes in this area too, so a test spin on drm-intel-nightly would be appreciated. Thanks.

Hey Jani,

So I grabbed the latest intel drm kernel from here:

http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/current/

In particular, linux-image-3.12.0-994-generic_3.12.0-994.201310150447_amd64

I tried it again...this time I booted with my two DP monitors plugged in. Started up fine, logged in...still good.

I switched the active workspace a few times left/right and then the first monitor blanked.

I did it a few more times and then the second monitor blanked.

I then physically undocked the laptop, detaching both screens and everything else, to send the captured system reports.

Here is a copy of the apport log dump from right after the error occurred:

http://www.crshman.com/debug/apport.xserver-xorg-video-intel.4x6KCY.apport_unpack/

Also, if you look at the CurrentDmesg file, around [21.961459] is where I pause for a second, then start switching the active workspace back and forth.

A few seconds later at [72.034577] is when the first monitor blanks off

What other debug information can I grab to help out with this?

Hello,

Is there anything else I can test/add to this report to help figure out what's going on?

Hello,

Is there anything I can test/add to this report to help figure out what's going on?

(In reply to comment #8)
> Hello,
> 
> Is there anything I can test/add to this report to help figure out what's
> going on?

Would be intresting to see if underruns persist with lower resolution modes.

(In reply to comment #9)
> Would be intresting to see if underruns persist with lower resolution modes.

Here are the different modes my monitors can do:

DP2 connected 1440x2560+1440+0 left (normal left inverted right x axis y axis) 597mm x 336mm
   2560x1440      60.0*+
   1920x1200      59.9  
   1920x1080      60.0     60.0     50.0     59.9     24.0     24.0  
   1920x1080i     60.1     50.0     60.0  
   1600x1200      60.0  
   1680x1050      60.0  
   1280x1024      75.0     60.0  
   1280x800       59.8  
   1152x864       75.0  
   1280x720       60.0     50.0     59.9  
   1024x768       75.1     60.0  
   800x600        75.0     60.3  
   720x576        50.0  
   720x480        60.0     59.9  
   640x480        75.0     60.0     59.9  
   720x400        70.1  

Any particular one you think would work best?

We've had piles and piles of watermark fixes, which should help in rectifying pipe underruns. Can you please retest with a recent drm-intel-nightly build?

Hey Daniel,

Sounds good, I'll update to the latest nightly and see how things go.

Created attachment 91827 [details]
01-10-2014 drm-intel-nightly

I've gone ahead and updated to the latest nightly:

Linux rnavarro-thinkpad 3.13.0-994-generic #201401100405 SMP Fri Jan 10 09:05:49 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

The release done on 1/10/14

I'm still getting the underruns. Right after I logged in I got one one my second monitor, and then shortly after another on my first.

The latest log can be found here (01-10-2014 drm-intel-nightly):

https://bugs.freedesktop.org/attachment.cgi?id=91827

Ville, any ideas?

Assuming the watermarks get computed correctly, the only issue i can think of is that the WM latency values provided by the BIOS might be too optimistic. My SNB machine has the same SSKPD though (not that I've ever tried dual 25x14 displays on it).

Does the problem occur with just one of the displays plugged in?

Or with two displays and lower resolution on both. 1920x1080@60 should be OK.

Can you take some register dumps (for the original dual 2560x1440 case)? I'd like to check it things look OK. As root run this:

intel_reg_read 0xc6014 0xc6040 0xc6044 0xc6018 0xc6048 0xc604c 0x45100 0x45104 
0x45108 0x4510c 0x45110 0x45120 0x145d10 0x42000 0x42004 0x42020 0x70180 0x71180

intel_reg_read is part of intel-gpu-tools.

Replies inline:

> Does the problem occur with just one of the displays plugged in?
I've never had this happen with only a single display.

> Or with two displays and lower resolution on both. 1920x1080@60 should be OK.
With both monitors 1920x1080@60 it doesn't happen

> Can you take some register dumps (for the original dual 2560x1440 case)? I'd
> like to check it things look OK. As root run this:
> 
> intel_reg_read 0xc6014 0xc6040 0xc6044 0xc6018 0xc6048 0xc604c 0x45100
> 0x45104 
> 0x45108 0x4510c 0x45110 0x45120 0x145d10 0x42000 0x42004 0x42020 0x70180
> 0x71180
> 
> intel_reg_read is part of intel-gpu-tools.
Do I run the intel_reg_read right after the problem has occurred, or when? (Never used that tool)

Thanks for looking into this guys, I'll do my best to get you all and any information you need to debug this!

(In reply to comment #17)
> Replies inline:
> 
> > Does the problem occur with just one of the displays plugged in?
> I've never had this happen with only a single display.
> 
> > Or with two displays and lower resolution on both. 1920x1080@60 should be OK.
> With both monitors 1920x1080@60 it doesn't happen
> 
> > Can you take some register dumps (for the original dual 2560x1440 case)? I'd
> > like to check it things look OK. As root run this:
> > 
> > intel_reg_read 0xc6014 0xc6040 0xc6044 0xc6018 0xc6048 0xc604c 0x45100
> > 0x45104 
> > 0x45108 0x4510c 0x45110 0x45120 0x145d10 0x42000 0x42004 0x42020 0x70180
> > 0x71180
> > 
> > intel_reg_read is part of intel-gpu-tools.
> Do I run the intel_reg_read right after the problem has occurred, or when?
> (Never used that tool)

You can run it as soon as the displays are lit up, and probably best to run it also after the problem has occured (just to make sure the registers haven't changed magically in between).

Created attachment 92058 [details]
kernel output

Created attachment 92059 [details]
reg_read_2014-01-14T09:33:48-0800.txt

Created attachment 92060 [details]
reg_read_2014-01-14T09:30:53-0800.txt

Created attachment 92061 [details]
reg_read_2014-01-14T09:30:42-0800.txt

Created attachment 92062 [details]
reg_read_2014-01-14T09:30:01-0800.txt

Created attachment 92063 [details]
reg_read_2014-01-14T09:29:03-0800.txt

Ok, i've gone ahead and bumped my kernel to this version:

Linux rnavarro-thinkpad 3.13.0-994-generic #201401140526 SMP Tue Jan 14 10:27:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

I went ahead and added a dump of the intel_reg_read output to rc.local to get an early dump.

I then manually ran a dump right when I logged in, and again a few more times after it happened again.

Here is the kernel log:
https://bugs.freedesktop.org/attachment.cgi?id=92058

P.S. This was a particularly good one, my main monitor didn't even turn back on this time after the underrun.

Also, to save you guys some time, I didn't notice any differences between any of the dumps from intel_reg_read

Hmm. The register dumps look perfectly fine. So the BIOS provided memory latency values being too low to keep the system happy remains my only theory.

Any chance there might be a BIOS update available for the machine? That might be worth a shot, although I can't guarantee that any update would affect the latency values.

In any case, I'll need to cook up some patches to allow run-time modification of the latency values, so that we can try and see if increasing them would actually help...

(In reply to comment #27)

> Any chance there might be a BIOS update available for the machine? That
> might be worth a shot, although I can't guarantee that any update would
> affect the latency values.
I took a look at the lenovo website and I'm currently running the latest BIOS revision, 1.39.

Created attachment 92540 [details] [review]
Patch to allow changing watermark latency values

This patch allows changing the latency values we use for computing the watermarks.

It adds three new debugfs files. "i915_pri_wm_latency" being the one we're interested in here.

Reading the file should give similar output as the kernel log had. So in this case it should look like this:

# cat i915_pri_wm_latency
Primary WM0 latency 7 (0.7 usec)
Primary WM1 latency 3 (1.5 usec)
Primary WM2 latency 4 (2.0 usec)
Primary WM3 latency 22 (11.0 usec)

What you could then do is write new latency values to the file. Let's say we try to double the latency values:
# echo '14 6 8 44' > i915_pri_wm_latency

Now reading the file again should show the new values. To actually make the system use them you'd need to force a modeset on all the displays.
"xset dpms force off; xset dpms force on" should be enough for that. After this is done you should see some change in the 0x45100 and 0x45104 registers.

And then it should just be a matter of trying to cause another underrun, and increasing the latency values until they no longer occur.

Hello,

I actually just updated my kernel version a few minutes ago to check to see how things were going.

I'm currently running:

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

Did this patch make it into the 01/21/14 nightly, or should I wait for the 01/22/14 nightly?

Additionally, where is the 'i915_pri_wm_latency' located?

I searched in /sys/kernel/debug and it didn't show up (which would make sense if the patch hadn't hit the nightly yet)

(In reply to comment #30)
> Hello,
> 
> I actually just updated my kernel version a few minutes ago to check to see
> how things were going.
> 
> I'm currently running:
> 
> 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
> 
> Did this patch make it into the 01/21/14 nightly, or should I wait for the
> 01/22/14 nightly?

I didn't even post it to the mailing list yet. I can do that if it's easier for you to test it through that prebuilt kernel.

> Additionally, where is the 'i915_pri_wm_latency' located?

It will show up in /sys/kernel/debug/dri/0/

(In reply to comment #31)
> I didn't even post it to the mailing list yet. I can do that if it's easier
> for you to test it through that prebuilt kernel.

Oops jumping the gun a bit, yes it would be much easier for me to test in a pre-built kernel.

Thanks for your efforts in helping resolve this!

(In reply to comment #32)
> (In reply to comment #31)
> > I didn't even post it to the mailing list yet. I can do that if it's easier
> > for you to test it through that prebuilt kernel.
> 
> Oops jumping the gun a bit, yes it would be much easier for me to test in a
> pre-built kernel.
> 
> Thanks for your efforts in helping resolve this!

Daniel picked up the patch for -nightly, so hopefully it'll appear in your prebuilt kernels soonish.

Ok, so it looks like I have this now.

root@rnavarro-thinkpad:/sys/kernel/debug/dri/0# cat i915_pri_wm_latency
WM0 7 (0.7 usec)
WM1 3 (1.5 usec)
WM2 4 (2.0 usec)
WM3 22 (11.0 usec)

root@rnavarro-thinkpad:/sys/kernel/debug/dri/0# echo '14 6 8 44' > i915_pri_wm_latency

root@rnavarro-thinkpad:/sys/kernel/debug/dri/0# cat i915_pri_wm_latency
WM0 14 (1.4 usec)
WM1 6 (3.0 usec)
WM2 8 (4.0 usec)
WM3 44 (22.0 usec)

Ran the commands just as described, would it make sense to figure out what the minimums are?

Does it matter which WMx I'm changing?

Should I change them all at the same time as described, or one by one?

(In reply to comment #34)
> Ok, so it looks like I have this now.
> 
> root@rnavarro-thinkpad:/sys/kernel/debug/dri/0# cat i915_pri_wm_latency
> WM0 7 (0.7 usec)
> WM1 3 (1.5 usec)
> WM2 4 (2.0 usec)
> WM3 22 (11.0 usec)
> 
> root@rnavarro-thinkpad:/sys/kernel/debug/dri/0# echo '14 6 8 44' >
> i915_pri_wm_latency
> 
> root@rnavarro-thinkpad:/sys/kernel/debug/dri/0# cat i915_pri_wm_latency
> WM0 14 (1.4 usec)
> WM1 6 (3.0 usec)
> WM2 8 (4.0 usec)
> WM3 44 (22.0 usec)
> 
> Ran the commands just as described, would it make sense to figure out what
> the minimums are?

I guess we can try to narrow it down as much as possible. If the doubled values work, then we could bisect it further to find the smallest acceptable value. If the doubled values didn't work, might want to try 3x,4x,5x...

> 
> Does it matter which WMx I'm changing?

With two displays only WM0 will be used. The others only kick in to provide more power savings in single display use cases.

> 
> Should I change them all at the same time as described, or one by one?

Probably best to keep changing all in sync for now. I think we at least need to maintain the relationship WM0<=WM1<=WM2<=WM3 (for the usec values).

Also probably a good idea to check at each step that the change resulted in a corresponding change to the 0x45100 and 0x45104 register values. In your two display case, those two registers should always have an identical value to each other.

I'm not noticing a change in the register values when I change the latencies:

root@rnavarro-thinkpad:~# cat /sys/kernel/debug/dri/0/i915_pri_wm_latency
WM0 7 (0.7 usec)
WM1 3 (1.5 usec)
WM2 4 (2.0 usec)
WM3 22 (11.0 usec)

root@rnavarro-thinkpad:~# intel_reg_read 0x45100 0x45104
0x45100 : 0xD0006
0x45104 : 0xD0006

root@rnavarro-thinkpad:~# echo '14 6 8 44' > /sys/kernel/debug/dri/0/i915_pri_wm_latency

root@rnavarro-thinkpad:~# cat /sys/kernel/debug/dri/0/i915_pri_wm_latency
WM0 14 (1.4 usec)
WM1 6 (3.0 usec)
WM2 8 (4.0 usec)
WM3 44 (22.0 usec)

root@rnavarro-thinkpad:~# intel_reg_read 0x45100 0x45104
0x45100 : 0xD0006
0x45104 : 0xD0006

Is that unexpected?

(In reply to comment #36)
> I'm not noticing a change in the register values when I change the latencies:
> 
> root@rnavarro-thinkpad:~# cat /sys/kernel/debug/dri/0/i915_pri_wm_latency
> WM0 7 (0.7 usec)
> WM1 3 (1.5 usec)
> WM2 4 (2.0 usec)
> WM3 22 (11.0 usec)
> 
> root@rnavarro-thinkpad:~# intel_reg_read 0x45100 0x45104
> 0x45100 : 0xD0006
> 0x45104 : 0xD0006
> 
> root@rnavarro-thinkpad:~# echo '14 6 8 44' >
> /sys/kernel/debug/dri/0/i915_pri_wm_latency
> 
> root@rnavarro-thinkpad:~# cat /sys/kernel/debug/dri/0/i915_pri_wm_latency
> WM0 14 (1.4 usec)
> WM1 6 (3.0 usec)
> WM2 8 (4.0 usec)
> WM3 44 (22.0 usec)
> 
> root@rnavarro-thinkpad:~# intel_reg_read 0x45100 0x45104
> 0x45100 : 0xD0006
> 0x45104 : 0xD0006
> 
> Is that unexpected?

Did you do the "xset dpms force off; xset dpms force on" commands in between?

Ah yes, forgot to run that command. Once I do that the register values are changed.

Doubling all of these numbers seems to work great. I'm trying to track down what the minimums are, I reset everything to the defaults and I'm slowly bumping WM0 (while keeping with WM0<=WM1<=WM2<=WM3) to see where things stop breaking.

So far so good with this:

root@rnavarro-thinkpad:~# cat /sys/kernel/debug/dri/0/i915_pri_wm_latency; intel_reg_read 0x45100 0x45104
WM0 10 (1.0 usec)
WM1 3 (1.5 usec)
WM2 4 (2.0 usec)
WM3 22 (11.0 usec)
0x45100 : 0x120006
0x45104 : 0x120006

WM0 7 (0.7 usec) --> WM0 10 (1.0 usec)

However, I'm going to keep testing to make sure that the WM0 1.0usec is solid.

Thanks for the assistance thus far, we're getting close to pinning this down!

Hey Guys,

So after a few days of testing I've seen zero flickers with this config:

root@rnavarro-thinkpad:~# cat /sys/kernel/debug/dri/0/i915_pri_wm_latency
WM0 12 (1.2 usec)
WM1 3 (1.5 usec)
WM2 4 (2.0 usec)
WM3 22 (11.0 usec)

So I went from:
WM0 7 (0.7 usec) --> WM0 12 (1.2 usec)

Created attachment 94766 [details] [review]
drm/i915: Increase WM memory latency values on SNB with high pixel clock

This patch should make the driver automagically increase the latency values when encoutering a high resolution display. Please test and report back whether it works as intended.

Sounds good, I'll keep an eye out for it on my prebuilt kernels and report back when it's merged in.

(In reply to comment #41)
> Sounds good, I'll keep an eye out for it on my prebuilt kernels and report
> back when it's merged in.

Nope, we won't merge this without positive testing feedback from you. Which means you need to apply this patch and build kernels yourself - we can't test every possible crazy hw combination out there ourselves and applying random patches to the main tree is a no-go (besides that usually it takes a bit of time for patches to land in pre-built kernels that way anyway).

If you can't test patches we need to close this as unresolved unfortunately.

Ok, I'll have to figure out how to compile the kernel for my OS. It may take some time, but I'll figure it out.

TL;DR The patch seems to correct my issue, which I've been directed to this bug after complaining about it on the Intel-gfx list. However my issue isn't exactly identical. I'm providing compiling instructions for Robert N to verify with also.

Some months ago I bought a cheap 27" S-IPS display off of ebay. The panel supports DVI, Displayport, and some others, and its native resolution is QHD 2560x1440. The display shipped from Korea, I plugged it into my Thinkpad X220 running Debian Sid and had a slew of issues. The seller went back and forth with me on trying to fix the issues, and provided replacement boards for the inside of the display, but ultimately the seller stalled and the one month period to request a refund flew by.

There are two issues I encounter...

Through a direct Displayport connection from my X220 to the monitor at full resolution, if there's a lot of motion on the screen (a full screen video or scrolling a web page back and forth) for about 60 seconds, the screen will blank out and return a few times until it acts as though the Displayport cable has been disconnected and there's no signal. Eventually the display will give up and go to sleep.

Through Displayport to Dual Link DVI via one of those adapters that requires power over USB, the display was more usable. During a lot of motion on the screen it wouldn't blank out, however after about 5 minutes of that all the pixels on the screen would vibrate together back and forth about 200px horizontally for half a second. This will repeat anywhere between every 30 seconds to 5 minutes. Again never blanking out.

If I drive the display at a smaller resolution like 1080p, I have no issues. The same goes with pushing over HDMI, but the max solution here is 1080p anyhow. Additional I haven't noticed this issue on most actual name brand displays, namely the higher priced Dell displays.

Recently I was getting fed up with this issue and started looking for a replacement monitor. After realizing that blowing another $500 sort of sucks, so I decided to do a little more testing. Using a spare Mac Mini I keep around for testing, I tested out Displayport to Displayport, playing a 1080p video on the display at full resolution. I encountered no issues (other than the Mac Mini simply dropping frames from the large video). Plugging in a spare drive I keep around with a bootable copy of Windows 7 into my Thinkpad X220, I again was able to drive the display playing full screen video with zero issues over Displayport.

Through out all my issues, I was never once able to find any sort of error or debug output in any logs. This includes kern.log, syslog and Xorg. Due to this I'm not sure if my issue is the same as Robert N's, and there for I would like it if he verified the fix too unless the devs here can safely say my issue described is the same.

So at this point I started to poke people on lists and bug some of my smarter kernel hacker friends, which has brought me to this bug.

After grabbing a copy of the drm-intel nightly source, applying the patch, compiling and giving it a spin, I was able to play a full screened video at full display resolution without issue over Displayport. I left the video playing for 2 hours, no blank outs, no shaking. I have not tested Dual Link DVI yet.


My kernel compiling steps, for Robert N:

# Some packages you might need, I'm most likely missing things here that I already have, you can figure it out
sudo apt-get install libncurses5-dev kernel-package

# Let's make a directory to get messy in
mkdir ~/temp-kernel
cd ~/temp-kernel

# Grab a copy of the patch
wget -O bug70254.patch https://bugs.freedesktop.org/attachment.cgi?id=94766

# Grab a copy of the nightly source, this will take a little while
git clone --depth=1 -b drm-intel-nightly git://people.freedesktop.org/~danvet/drm-intel

# Apply the patch
cd drm-intel
patch -p1 < ../bug70254.patch

# Copy your current kernel's config, this'll be different for you
cp /boot/config-3.12-1-amd64 .config

# Get the config ready for the new kernel, once this opens simply select save, save it at .config, and exit
make menuconfig

# We're now going to compile using fakeroot make-kpkg. This is a more sensible Debian way of putting together and installing kernels. In the end you should have two deb packages which you can later on apt-get remove easily if you want to. This (should) also takes care of updating grub.

# Provide the number of cores you want to dedicate to compiling, if you don't know just select 1
export CONCURRENCY_LEVEL=3

# Start compiling and build a pair of deb packages for you, this will take a long while
fakeroot make-kpkg --initrd --append-to-version=-custom-drm-intel-nightly-bug70254 kernel-image kernel-headers modules_image

# You should now have two deb packages, linux-image and linux-headers, named along with the version number
cd ..
ls -la

# Install the new packages, which should be the only two debs in the current wo
sudo dpkg -i linux-*.deb

# Reboot , there is a chance you need to select the kernel by hand when grub pops up during boot. I'm not sure how that all works in the Ubuntu world but I'm sure you can figure it out.

# When you've booted up, verify you've running they new patched kernel
uname -a

# I see: Linux lines 3.13.0-custom01+ #1 SMP Tue Mar 11 10:51:56 PDT 2014 x86_64 GNU/Linux
# Test away!


With all that being said if this patch gets accepted, approximately how soon till it might end up in a stable release of mainline kernel? Though honestly this current nightly kernel seems to be running a-ok thus far.

Additionally if I got a new fangled Lenovo dock with two Displayports, will I be able to drive two of the same displays at full resolution with this patch? I do understand I'll have to disable the laptop display to make the second external work.

Thanks!

Hey rubin110!

Thanks for the incredibly detailed instructions! (Stashing those away for the future!)

I'm compiling the new kernel as I write this, once it's done I'll reboot and start testing.

>>Additionally if I got a new fangled Lenovo dock with two Displayports, will I >>be able to drive two of the same displays at full resolution with this patch? I >>do understand I'll have to disable the laptop display to make the second >>external work.

The answer is YES! I actually drive my dual screens (3x Dell U2713HM) using this docking station:

http://www.amazon.com/gp/product/B0085MQLGC

Using both of the DP connectors.

I got this compiled and running yesterday, worked for the rest of the evening without issues, I'll keep poking at it today to see how it goes. But things are definitely looking promising!

So far so good with this patch, no flickers, no blanking and I didn't even have to touch any of the wm_latency params.

I've tested this on both 3.13 and 3.14rc6 (currently running on 3.14) and things look great.

Thanks for all the hard work guys!

Hey Guys,

So about an hour ago I rebooted and forgot to select the custom kernel on boot up. Within 5 minutes screens were blanking and flickering like crazy....then I realized I was on the stock kernel.

I just wanted to stop and say thanks again for all the hard work, this has changed my computing experience greatly!

So far I've spent two days on the newly patched kernel with zero issues at all.

(In reply to comment #40)
> Created attachment 94766 [details] [review] [review]
> drm/i915: Increase WM memory latency values on SNB with high pixel clock
> 
> This patch should make the driver automagically increase the latency values
> when encoutering a high resolution display. Please test and report back
> whether it works as intended.

Backported this patch on top of latest 3.13 based Ubuntu kernel tree, and indeed fixed the issue described by this bug (you can find more details at https://bugs.launchpad.net/xserver-xorg-video-intel/+bug/1239186).

Let me know if you need any further testing before sending the patch upstream.

(In reply to comment #40)
> Created attachment 94766 [details] [review] [review]
> drm/i915: Increase WM memory latency values on SNB with high pixel clock
> 
> This patch should make the driver automagically increase the latency values
> when encoutering a high resolution display. Please test and report back
> whether it works as intended.

Ville, has this been posted on the ml?

Anything else us testers need to do to get this bug into a fixed verified state? Thanks.

I posted Ville's patch for review [1]. Some further work is needed.

[1] http://mid.gmane.org/1395392448-6337-1-git-send-email-jani.nikula@intel.com

Where there any changes required for the posted patch?

Any indication on when it'll get pushed out so I can start running pre-compiled kernels again?

I know how to compile my own now, thanks rubin110, but it's far more convenient to not have to waste my time building a kernel.

Hey Guys,

I've asked around and the consensus is that the patch "still needs work" but I'm not sure what that work might be.

What other things are needed for this to get included?

I had the same issue. Ville's patch solved the problem. Thanks a lot guys. I wish you all the best!

Just as a heads up to all following this bug. Ville posted a cleaner patch here for testing:

http://patchwork.freedesktop.org/patch/25568/

Fix pushed to drm-intel-fixes as

commit 94b93bc0093a37230ea7a0e91f04bfce677c430f
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Thu May 8 15:09:19 2014 +0300

    drm/i915: Increase WM memory latency values on SNB

Thanks for the report.

(In reply to comment #57)
> Fix pushed to drm-intel-fixes as

commit e95a2f7509f5219177d6821a0a8754f93892ca56

> Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Date:   Thu May 8 15:09:19 2014 +0300
> 
>     drm/i915: Increase WM memory latency values on SNB
> 
> Thanks for the report.

Closing due to "patch solved the problem"