Launchpad has imported 50 comments from the remote bug at https://bugs.freedesktop.org/show_bug.cgi?id=70254.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2013-10-07T20:55:49+00:00 Robert Navarro wrote: Created attachment 87256 kernel error output I'm not sure if this is the right place, but based on the error log it seemed right. Anyways, I tried plugging in my two Dell monitors via display port to my Lenovo x220 machine and it generated these errors in the system log. I'm not sure if it's related, but the primary reason I opened this bug was because the monitors will blank after a few minutes of activity. The timeout period seems random and I can't really correlate it with any one activity. I'm running the latest version of the intel graphics drivers, 2013Q3. ## lspci output 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) ## uname -a output Linux rnavarro-thinkpad 3.8.0-31-generic #46-Ubuntu SMP Tue Sep 10 20:03:44 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux ## lsb_release -a output No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 13.04 Release: 13.04 Codename: raring ## aptitude show libdrm-intel1 output Package: libdrm-intel1 State: installed Automatically installed: no Multi-Arch: same Version: 2.4.45-0ubuntu1 Priority: optional Section: libs Maintainer: Ubuntu Developers <ubuntu-devel-disc...@lists.ubuntu.com> Architecture: amd64 Uncompressed Size: 189 k Depends: libc6 (>= 2.17), libdrm2 (>= 2.4.38), libpciaccess0 PreDepends: multiarch-support Breaks: libdrm-intel1 (!= 2.4.45-0ubuntu1) Replaces: libdrm-intel1 (< 2.4.45-0ubuntu1) Description: Userspace interface to intel-specific kernel DRM services -- runtime This library implements the userspace interface to the intel-specific kernel DRM services. DRM stands for "Direct Rendering Manager", which is the kernelspace portion of the "Direct Rendering Infrastructure" (DRI). The DRI is currently used on Linux to provide hardware-accelerated OpenGL drivers. ## aptitude show libdrm2 output Package: libdrm2 State: installed Automatically installed: no Multi-Arch: same Version: 2.4.45-0ubuntu1 Priority: optional Section: libs Maintainer: Ubuntu Developers <ubuntu-devel-disc...@lists.ubuntu.com> Architecture: amd64 Uncompressed Size: 103 k Depends: libc6 (>= 2.17) PreDepends: multiarch-support Breaks: libdrm2 (!= 2.4.45-0ubuntu1) Replaces: libdrm2 (< 2.4.45-0ubuntu1) Description: Userspace interface to kernel DRM services -- runtime This library implements the userspace interface to the kernel DRM services. DRM stands for "Direct Rendering Manager", which is the kernelspace portion of the "Direct Rendering Infrastructure" (DRI). The DRI is currently used on Linux to provide hardware-accelerated OpenGL drivers. This package provides the runtime environment for libdrm. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/0 ------------------------------------------------------------------------ On 2013-10-07T20:56:23+00:00 Robert Navarro wrote: Created attachment 87257 glxinfo output Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/1 ------------------------------------------------------------------------ On 2013-10-07T20:57:10+00:00 Robert Navarro wrote: 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) Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/2 ------------------------------------------------------------------------ On 2013-10-08T07:13:57+00:00 Jani-nikula wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/3 ------------------------------------------------------------------------ On 2013-10-12T18:39:45+00:00 Robert Navarro wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/4 ------------------------------------------------------------------------ On 2013-10-14T09:54:08+00:00 Jani-nikula wrote: Updating subject accordingly. We probably have fixes in this area too, so a test spin on drm-intel-nightly would be appreciated. Thanks. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/8 ------------------------------------------------------------------------ On 2013-10-15T20:30:26+00:00 Robert Navarro wrote: 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/33 ------------------------------------------------------------------------ On 2013-10-21T17:34:58+00:00 Robert Navarro wrote: Hello, Is there anything else I can test/add to this report to help figure out what's going on? Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/35 ------------------------------------------------------------------------ On 2013-11-10T20:53:35+00:00 Robert Navarro wrote: Hello, Is there anything I can test/add to this report to help figure out what's going on? Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/37 ------------------------------------------------------------------------ On 2014-01-03T11:11:36+00:00 Mika-kuoppala wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/38 ------------------------------------------------------------------------ On 2014-01-03T15:10:16+00:00 Robert Navarro wrote: (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? Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/39 ------------------------------------------------------------------------ On 2014-01-08T17:15:16+00:00 Daniel-ffwll wrote: 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/41 ------------------------------------------------------------------------ On 2014-01-08T17:43:35+00:00 Robert Navarro wrote: Hey Daniel, Sounds good, I'll update to the latest nightly and see how things go. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/42 ------------------------------------------------------------------------ On 2014-01-10T16:53:31+00:00 Robert Navarro wrote: Created attachment 91827 01-10-2014 drm-intel-nightly Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/43 ------------------------------------------------------------------------ On 2014-01-10T16:54:31+00:00 Robert Navarro wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/44 ------------------------------------------------------------------------ On 2014-01-14T13:51:03+00:00 Daniel-ffwll wrote: Ville, any ideas? Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/45 ------------------------------------------------------------------------ On 2014-01-14T16:08:40+00:00 Ville-syrjala-e wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/46 ------------------------------------------------------------------------ On 2014-01-14T16:13:47+00:00 Robert Navarro wrote: 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! Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/47 ------------------------------------------------------------------------ On 2014-01-14T16:18:33+00:00 Ville-syrjala-e wrote: (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). Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/48 ------------------------------------------------------------------------ On 2014-01-14T17:35:39+00:00 Robert Navarro wrote: Created attachment 92058 kernel output Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/49 ------------------------------------------------------------------------ On 2014-01-14T17:36:18+00:00 Robert Navarro wrote: Created attachment 92059 reg_read_2014-01-14T09:33:48-0800.txt Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/50 ------------------------------------------------------------------------ On 2014-01-14T17:36:32+00:00 Robert Navarro wrote: Created attachment 92060 reg_read_2014-01-14T09:30:53-0800.txt Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/51 ------------------------------------------------------------------------ On 2014-01-14T17:36:49+00:00 Robert Navarro wrote: Created attachment 92061 reg_read_2014-01-14T09:30:42-0800.txt Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/52 ------------------------------------------------------------------------ On 2014-01-14T17:37:16+00:00 Robert Navarro wrote: Created attachment 92062 reg_read_2014-01-14T09:30:01-0800.txt Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/53 ------------------------------------------------------------------------ On 2014-01-14T17:37:30+00:00 Robert Navarro wrote: Created attachment 92063 reg_read_2014-01-14T09:29:03-0800.txt Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/54 ------------------------------------------------------------------------ On 2014-01-14T17:40:00+00:00 Robert Navarro wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/55 ------------------------------------------------------------------------ On 2014-01-14T17:48:40+00:00 Robert Navarro wrote: Also, to save you guys some time, I didn't notice any differences between any of the dumps from intel_reg_read Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/56 ------------------------------------------------------------------------ On 2014-01-20T17:30:19+00:00 Ville-syrjala-e wrote: 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... Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/57 ------------------------------------------------------------------------ On 2014-01-20T17:42:07+00:00 Robert Navarro wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/58 ------------------------------------------------------------------------ On 2014-01-21T19:45:15+00:00 Ville-syrjala-e wrote: Created attachment 92540 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/59 ------------------------------------------------------------------------ On 2014-01-21T19:53:00+00:00 Robert Navarro wrote: 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) Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/60 ------------------------------------------------------------------------ On 2014-01-22T08:42:24+00:00 Ville-syrjala-e wrote: (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/ Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/61 ------------------------------------------------------------------------ On 2014-01-22T15:12:26+00:00 Robert Navarro wrote: (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! Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/62 ------------------------------------------------------------------------ On 2014-01-28T20:02:15+00:00 Ville-syrjala-e wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/63 ------------------------------------------------------------------------ On 2014-01-29T16:52:33+00:00 Robert Navarro wrote: 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/64 ------------------------------------------------------------------------ On 2014-01-29T17:05:57+00:00 Ville-syrjala-e wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/65 ------------------------------------------------------------------------ On 2014-01-29T18:05:30+00:00 Robert Navarro wrote: 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/66 ------------------------------------------------------------------------ On 2014-01-29T18:32:27+00:00 Ville-syrjala-e wrote: (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? Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/67 ------------------------------------------------------------------------ On 2014-01-30T16:43:02+00:00 Robert Navarro wrote: 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! Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/68 ------------------------------------------------------------------------ On 2014-02-02T00:36:05+00:00 Robert Navarro wrote: 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) Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/69 ------------------------------------------------------------------------ On 2014-02-26T13:16:26+00:00 Ville-syrjala-e wrote: Created attachment 94766 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/70 ------------------------------------------------------------------------ On 2014-03-02T06:43:07+00:00 Robert Navarro wrote: Sounds good, I'll keep an eye out for it on my prebuilt kernels and report back when it's merged in. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/71 ------------------------------------------------------------------------ On 2014-03-03T07:32:36+00:00 Daniel-ffwll wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/72 ------------------------------------------------------------------------ On 2014-03-03T15:08:58+00:00 Robert Navarro wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/73 ------------------------------------------------------------------------ On 2014-03-11T20:00:36+00:00 rubin110 wrote: 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! Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/77 ------------------------------------------------------------------------ On 2014-03-12T20:50:32+00:00 Robert Navarro wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/78 ------------------------------------------------------------------------ On 2014-03-13T14:32:33+00:00 Robert Navarro wrote: 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! Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/79 ------------------------------------------------------------------------ On 2014-03-14T14:40:00+00:00 Robert Navarro wrote: 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! Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/80 ------------------------------------------------------------------------ On 2014-03-14T23:22:49+00:00 Robert Navarro wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/81 ------------------------------------------------------------------------ On 2014-03-16T19:52:07+00:00 Ricardo Salveti wrote: (In reply to comment #40) > 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. 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1239186/comments/84 ** Changed in: xserver-xorg-video-intel Status: Unknown => Incomplete ** Changed in: xserver-xorg-video-intel Importance: Unknown => Medium -- You received this bug notification because you are a member of Ubuntu-X, which is subscribed to xserver-xorg-video-intel in Ubuntu. https://bugs.launchpad.net/bugs/1239186 Title: [Lenovo ThinkPad X220] External screens shut off randomly To manage notifications about this bug go to: https://bugs.launchpad.net/xserver-xorg-video-intel/+bug/1239186/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~ubuntu-x-swat Post to : ubuntu-x-swat@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-x-swat More help : https://help.launchpad.net/ListHelp
