Created attachment 119412 [details] 4.3.0 -drm-intel-nightly dmesg, drm info, intel_reg dump, vbios, xrandr verbose On the Braswell NUC NUC5CPYB (and another Lenovo platform) while using multiple connected outputs, one can cause the second output (DP2/HDMI2) to go to a solid color and/blank until reboot. On this NUC, the HDMI is port 2, on Lenovo hardware I can interchange all output types on both ports and produce this result as well (DP,HDMI,VGA,DVI) Attached are debug information from Arch Linux kernels 4.2.5, 4.3.0 and 4.3.0 built from drm-intel-nightly To reproduce: - Attached both outputs - boot into X/desktop - configure monitors as separate displays - move cursor across screen borders between the two monitors at a high rate (wiggle the mouse fast) You will see: - At first, a slight flicker of the display, or a tarnish of the coloring of DP2 - DP2's output will eventually block into a single color - dmesg will have an output regarding drm:intel_cpu_fifo_underrun Attached will be a tarball of the information requested for all three kernels.
Created attachment 119413 [details] 4.2.5 dmesg, drm-info, xrander verbose
Created attachment 119414 [details] 4.3.0 dmesg, drm-info, intel_reg, vbios, xrandr verbose
Bumped to high. This is blocking a product release
Please try current drm-intel-nightly, add drm.debug=14 module parameter, and attach the (plain text!) dmesg all the way from boot to reproducing the problem. If the early boot doesn't fit in the buffer, please add log_buf_len=4M (or larger) and try again. (In reply to Jason Plum from comment #3) > Bumped to high. This is blocking a product release This bugzilla is best-effort only. If you have a support contract with Intel, please escalate through your normal support channels.
Xorg.0.log might prove to be interesting too.
(In reply to Jani Nikula from comment #4) > Please try current drm-intel-nightly, add drm.debug=14 module parameter, and > attach the (plain text!) dmesg all the way from boot to reproducing the > problem. If the early boot doesn't fit in the buffer, please add > log_buf_len=4M (or larger) and try again. I will rebuild and re-test. I will not pre-compress them this time. Might I ask why drm.debug=14 vs the drm.debug=0x1e that I have? (documentation purposes for my team) > (In reply to Jason Plum from comment #3) > > Bumped to high. This is blocking a product release > > This bugzilla is best-effort only. If you have a support contract with > Intel, please escalate through your normal support channels. Understood. I have sent my manufacturer this bug and they are going through said channels.
(In reply to Jani Nikula from comment #5) > Xorg.0.log might prove to be interesting too. I can provide that along with it, but according to Xorg, it this the output/monitor is still there and in use.
(In reply to Jason Plum from comment #6) > (In reply to Jani Nikula from comment #4) > > Please try current drm-intel-nightly, add drm.debug=14 module parameter, and > > attach the (plain text!) dmesg all the way from boot to reproducing the > > problem. If the early boot doesn't fit in the buffer, please add > > log_buf_len=4M (or larger) and try again. > > I will rebuild and re-test. Thanks. > I will not pre-compress them this time. Might I ask why drm.debug=14 vs the > drm.debug=0x1e that I have? (documentation purposes for my team) It's a bit mask; see include/drm/drmP.h in the kernel tree for the bit definitions. 0x10 is atomic modeset debugging; it's pretty verbose, I personally prefer to not include that unless I think it's needed. Makes it easier to read the logs without it, but others may have different preferences... > > (In reply to Jason Plum from comment #3) > > > Bumped to high. This is blocking a product release > > > > This bugzilla is best-effort only. If you have a support contract with > > Intel, please escalate through your normal support channels. > > Understood. I have sent my manufacturer this bug and they are going through > said channels. Thanks.
(In reply to Jason Plum from comment #7) > (In reply to Jani Nikula from comment #5) > > Xorg.0.log might prove to be interesting too. > > I can provide that along with it, but according to Xorg, it this the > output/monitor is still there and in use. Okay, I was thinking perhaps there are some clues there.
Created attachment 119598 [details] 4.3.0-drm-intel-nightly-20151112-dmesg
Created attachment 119599 [details] 4.3.0-drm-intel-nightly-20151112-Xorg.log
Created attachment 119600 [details] 4.3.0-drm-intel-nightly-20151112-vbios dump
Created attachment 119601 [details] 4.3.0-drm-intel-nightly-20151112- xrandr verbose
Created attachment 119602 [details] 4.3.0-drm-intel-nightly-20151112 intel reg dump
Now attached are all the logs and files, plus Xorg.log, from 4.3.0+ drm-intel-nightly as of 2015-11-12 (Thu Nov 12 15:29:10 UTC 2015)
Ville, please have a look at the attached dmesg. There's more of this than I've seen before: [ 32.634763] [drm:vlv_pipe_set_fifo_size] Pipe A FIFO split 511 / 511 / 511 [ 32.634833] [drm:vlv_pipe_set_fifo_size] Pipe C FIFO split 511 / 511 / 511 [ 32.634843] [drm:vlv_update_wm] Setting FIFO watermarks - C: plane=391, cursor=0, sprite0=0, sprite1=0, SR: plane=0, cursor=0 level=0 cxsr=0
Created attachment 119628 [details] [review] [PATCH] drm/i915: Always keep cursor WM at its highest on VLV/CHV Potential hack to fix the underruns from premature cursor wm programming.
I have tried this patch, but while it does increase the effort required, the problem can still be replicated. I will attach logs from this in the coming day (GMT+5)
Bug scrub: Assigned to Jason Plum to provide the logs.
Logs forthcoming, using drm-intel-fixes as of Dec-6-2015, 4.4.0-rc4 merge. We've discovered this is BSW specific, and only related to DP3/CRTC2 somehow. To replicate, bring up a connected display as a display/screen in X, and move the mouse rapidly to/across Horizontal 0. You will see the flicker, and an approximate 10 pixel shift right of the entire display, with the excess on the right of the screen wrapping back to the left side. More logs incoming.
danvet (irc) is having me try the previous patch, in addition to this: http://paste.debian.net/plain/342677 Will provide feedback & logs shortly.
Created attachment 120441 [details] drm-intel-fixes dec-06-2015 plus patches kernel messages Attaching the kernel messages from this boot. Initial test showed that the bug occurred. Then `xset dpms force off && xset dpms set force on` resulted in the monitor coming back without a cursor. This was resolved by configuring it mirrored (all cursor lost), and then as separate displays. Now, I can get it to recur, but within ~1 second it returns to functioning. Problem being that is has to be forcibly reset with the `xset dpms` calls
Created attachment 120531 [details] [review] [PATCH v2] drm/i915: Always keep cursor WM at its highest on VLV/CHV Improved hack. The old one failed to work at all.
Created attachment 120549 [details] drm-intel-fixes@2015-12-06 + attachment 120531 [details] [review] Adding this patch to drm-intel-fixes @ 2015-12-06 and no other patches, we end up with nothing better. Full dmesg attached.
http://lists.freedesktop.org/archives/intel-gfx/2015-December/083563.html
Having tested the last attached patched, it resulting in DP1 being, well, horrible when DP3 was not attached. The patch from the mailing list (Ville Syrjala) does appear to fix/work around this issue entirely. Preparing full regression tests.
So far, this has proven to work with each output individually, and in pairs. Preparing to test all 3 at once. Only issue I have seen is the wake-up delay on DP-HDMI causing problems.
I have now tested with all three monitors attached, in all combinations at aside from a single white flicker at the first crossing of the DP3 Horizonal 0 with the cursor, no other issue seems to persist during use.
commit ef8dd37af85a8f37ca3a29074647511e52c56181 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Fri Dec 18 19:24:39 2015 +0200 drm/i915: Workaround CHV pipe C cursor fail
I verified this on a Cyan DVT running Coreboot 7287.57.32 and Google Partner image R50 7982 2/28. After plugging in the HDMI monitor and moving the cursor quickly across the display border there was no issue with the screen going blank. Issue is fixed, can not reproduce.
*** Bug 93098 has been marked as a duplicate of this bug. ***
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.