| Summary: | [snb] External DP monitor goes black during heavy display activity | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | Jonathan Adamczewski <jadamcze> | ||||||
| Component: | DRM/Intel | Assignee: | Ville Syrjala <ville.syrjala> | ||||||
| Status: | CLOSED FIXED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||
| Severity: | normal | ||||||||
| Priority: | medium | ||||||||
| Version: | unspecified | ||||||||
| Hardware: | x86-64 (AMD64) | ||||||||
| OS: | Linux (All) | ||||||||
| Whiteboard: | |||||||||
| i915 platform: | i915 features: | ||||||||
| Attachments: |
|
||||||||
Hmm, can you try 'echo 0 > /sys/modules/drm_kms_helper/parameters/poll' or append drm_kms_helper.poll=0 to your kernel command line? (In reply to comment #1) > Hmm, can you try 'echo 0 > /sys/modules/drm_kms_helper/parameters/poll' or > append drm_kms_helper.poll=0 to your kernel command line? No change - screen went black during video playback. Since you have 3.7 on an ILK processor you will be affected by bug 55984. So I fear the suggestion about modesetting sent me off on a wild goose chase as I assumed the reason why you didn't attach a dmesg or Xorg.log in this case was because you had checked and cleared them of any errors. Created attachment 73709 [details]
dmesg showing nothing of interest when screen goes black
dmesg as previously posted to intel-gfx list, showing no entries when screen goes black
Created attachment 73710 [details]
xorg log showing no entry when external screen goes black
xorg.0.log. Nothing is written to this file when the external screen goes black.
(In reply to comment #3) > Since you have 3.7 on an ILK processor you will be affected by bug 55984. Based on the comments in that bug, I have the "band-aid" for that bug in 3.7.3. > So I fear the suggestion about modesetting sent me off on a wild goose chase as > I assumed the reason why you didn't attach a dmesg or Xorg.log in this case > was because you had checked and cleared them of any errors. I've attached them for reference - they have been checked and (to the best of my knowledge) are unenlightening. Is this still an issue, now that the ilk regression in 3.7 is again properly fixed? (In reply to comment #7) > Is this still an issue, now that the ilk regression in 3.7 is again properly > fixed? Closing this, based on the above. Jonathan please reopen this if you still see the problem with the latest kernel from git://people.freedesktop.org/~danvet/drm-intel drm-intel-nightly branch. This does still occur - I run the external monitor at 1920x1080 at which it happens a lot less frequently, but it still happens. Current kernel is 3.10.7, xf86-video-intel-2.21.14. (In reply to comment #9) > This does still occur - I run the external monitor at 1920x1080 at which it > happens a lot less frequently, but it still happens. > > Current kernel is 3.10.7, xf86-video-intel-2.21.14. The question was, does it happen with the latest kernel from git://people.freedesktop.org/~danvet/drm-intel drm-intel-nightly branch. (In reply to comment #10) > The question was, does it happen with the latest kernel from > git://people.freedesktop.org/~danvet/drm-intel drm-intel-nightly branch. Jonathan, ping for the test results on drm-intel-nightly. Tested with drm-intel-nightly 06653b7 and experienced the same problem. (In reply to comment #12) > Tested with drm-intel-nightly 06653b7 and experienced the same problem. Can you please boot with drm.debug=0xe and check whether you see any "FIFO underrun" reports? (In reply to comment #13) > (In reply to comment #12) > > Tested with drm-intel-nightly 06653b7 and experienced the same problem. > > Can you please boot with drm.debug=0xe and check whether you see any "FIFO > underrun" reports? Playing 4k youtube video, the screen went back and this was logged : [drm:ilk_display_irq_handler], Pipe B FIFO underrun [drm:cpt_serr_int_handler], PCH transcoder B FIFO underrun (In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #12) > > > Tested with drm-intel-nightly 06653b7 and experienced the same problem. > > > > Can you please boot with drm.debug=0xe and check whether you see any "FIFO > > underrun" reports? > > Playing 4k youtube video, the screen went back and this was logged : > > [drm:ilk_display_irq_handler], Pipe B FIFO underrun > [drm:cpt_serr_int_handler], PCH transcoder B FIFO underrun Can you please attach the complete dmesg (with debugging enable) where an underrun happens? Just so that we have a bit of context of what's going on around. But sounds like you need the watermark fixes Ville is working on. Seems like this is another case of high resolution display on SNB w/ inadequate BIOS provided memory latency values. First please try with latest drm-intel-nightly, and also provide the full dmesg w/ drm.debug=0xe. The watermark code has changed sinificantly since your last attempt. If that doesn't help, then please try increasing the memory latency values as shown in bug 70254, comment 39 Presumed fixed by 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 Please reopen if the problem persists with recent kernels. Closing |
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.
Dell XPS L702x laptop, xorg log reports "Integrated Graphics Chipset: Intel(R) Sandybridge Mobile (GT2)" Running a custom configured 3.7.3 based kernel, xf86-video-intel-2.20.18. I'm running the internal LVDS screen at 1080p and a Dell 2713HM monitor at 2560x1440 connected via display port. Both screens run fine when X starts, but at some point the external monitor will go black. The system doesn't recognize it as being disconnected - no KDE popup asking if I want to change the monitor config as happens when pulling the DP or power on the monitor. Sometimes it will return to life after a short amount of time, most of the time it stays black indefinitely. A full power cycle of the monitor (pulling the plug) will usually bring it back to life, as will unplugging and replugging the DP cable. The screen usually goes black while there's a high degree of display activity - a video playing, moving large windows around the screen, looking around in google streetview, heavy output in a large terminal window, etc. It doesn't seem to matter which screen the activity is on. It *seems* to be less likely if I run the external display at a lower resolution. There's nothing that coincides with the screen going black in dmesg or the xorg log, even with drm.debug=0xe on the command line. Testing using this patch: diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 1492706..5e91242 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -2580,6 +2580,8 @@ intel_dp_hot_plug(struct intel_encoder *intel_encoder) { struct intel_dp *intel_dp = enc_to_intel_dp(&intel_encoder->base); + printk("hotplug interrupt for DP\n"); + intel_dp_check_link_status(intel_dp); } there was no hotplug interrupt triggered when the screen goes black. I've had no problems with this monitor under Windows 7 (gaming, videos, etc). Earlier discussion regarding this issue may be found here: http://lists.freedesktop.org/archives/intel-gfx/2013-January/023874.html