Bug 86377

Summary: [HSW ULT GT3 DP] Blank screen at 3840x2160 resolution (both framebuffer and Xorg)
Product: DRI Reporter: Brian Campbell <brian.campbell>
Component: DRM/IntelAssignee: Intel GFX Bugs mailing list <intel-gfx-bugs>
Status: CLOSED DUPLICATE QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: normal    
Priority: medium CC: intel-gfx-bugs, przanoni, ville.syrjala
Version: XOrg git   
Hardware: Other   
OS: All   
See Also: https://bugs.freedesktop.org/show_bug.cgi?id=85621
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Output of journalctl
none
cat /proc/cpuinfo
none
Ouptut of dmesg
none
Ouptut of dmidecode
none
Output of intel_reg_dumper
none
Output of lspci -v
none
vbios dump
none
Xorg.0.log
none
xrandr --verbose output none

Description Brian Campbell 2014-11-17 08:30:57 UTC
Created attachment 109593 [details]
Output of journalctl

I tried installing Debian Jessie to an Intel NUC D5425WYK (BIOS version WYLPT10H.86A.0026.2014.0514.1714), attached to a Lenovo LI2821 3840x2160 monitor via DisplayPort. The installer shows up fine, GRUB shows up fine, and the early console shows up fine to prompt me to enter my disk encryption password, all at a lower resolution than native. But once we get far enough in to try modesetting to the full native resolution, the display goes black. Neither virtual terminals on the framebuffer nor Xorg show up.

After playing around with it a bit, I discovered that I could get lower resolutions, such as 1920x1080, to work as long as I increased the BIOS reserved video RAM to the maximum amount (I haven't yet tried bisecting the amount to see where the cutoff is; it was at the minimum value at first, I changed it to the max and it worked). But in order to get any output at all, I had to manually run "xrandr --output DP1 --mode 1920x1080", and manually set the "video=1920x1080@60" boot parameter in order to get the virtual terminals to show up.

The relevant error in the logs appears to be the following; this happens whenever I have one of X or the framebuffer set to a lower resolution (which works), and switch to the native 3840x2160 display resolution:

Nov 17 02:57:49 scratch kernel: [drm:ivybridge_set_fifo_underrun_reporting] *ERROR* uncleared fifo underrun on pipe A
Nov 17 02:57:49 scratch kernel: [drm:ivb_err_int_handler] *ERROR* Pipe A FIFO underrun

Distro: Debian Jessie
Motherboard: D54250WYK
CPU: Intel Core i5-4250U
Chipset: Haswell-ULT/HD 5000 (not sure what the actual name is, Haswell-ULT is what lspci report, HD 5000 is what the spec sheet reports)
Display Connector: DisplayPort (DP1)

$ uname -a
Linux scratch 3.16.0-4-amd64 #1 SMP Debian 3.16.7-2 (2014-11-06) x86_64 GNU/Linux

Reproduce steps: 100% reproducible. Boot. Screen is black until SSHing in and running "xrandr --output DP1 --mode 1920x1080", or setting GRUB command line to include "video=1920x1080@60" and switching to a virtual terminal.

Various relevant package versions:

ii  libdrm-intel1:amd64          2.4.58-2       amd64        Userspace interface to intel-specific kernel DRM services -- runtime
ii  libegl1-mesa:amd64           10.3.2-1       amd64        free implementation of the EGL API -- runtime
ii  libegl1-mesa-drivers:amd64   10.3.2-1       amd64        free implementation of the EGL API -- hardware drivers
ii  libgl1-mesa-dri:amd64        10.3.2-1       amd64        free implementation of the OpenGL API -- DRI modules
ii  libgl1-mesa-glx:amd64        10.3.2-1       amd64        free implementation of the OpenGL API -- GLX runtime
ii  libglapi-mesa:amd64          10.3.2-1       amd64        free implementation of the GL API -- shared library
ii  libglu1-mesa:amd64           9.0.0-2        amd64        Mesa OpenGL utility library (GLU)
ii  libopenvg1-mesa:amd64        10.3.2-1       amd64        free implementation of the OpenVG API -- runtime
ii  libwayland-egl1-mesa:amd64   10.3.2-1       amd64        implementation of the Wayland EGL platform -- runtime
ii  mesa-utils                   8.2.0-1        amd64        Miscellaneous Mesa GL utilities
ii  xorg                         1:7.7+7        amd64        X.Org X Window System
ii  xserver-xorg-video-intel     2:2.21.15-2+b2 amd64        X.Org X server -- Intel i8xx, i9xx display driver
Comment 1 Brian Campbell 2014-11-17 08:31:24 UTC
Created attachment 109594 [details]
cat /proc/cpuinfo
Comment 2 Brian Campbell 2014-11-17 08:31:51 UTC
Created attachment 109595 [details]
Ouptut of dmesg
Comment 3 Brian Campbell 2014-11-17 08:32:09 UTC
Created attachment 109596 [details]
Ouptut of dmidecode
Comment 4 Brian Campbell 2014-11-17 08:32:26 UTC
Created attachment 109597 [details]
Output of intel_reg_dumper
Comment 5 Brian Campbell 2014-11-17 08:32:45 UTC
Created attachment 109598 [details]
Output of lspci -v
Comment 6 Brian Campbell 2014-11-17 08:33:02 UTC
Created attachment 109599 [details]
vbios dump
Comment 7 Brian Campbell 2014-11-17 08:33:20 UTC
Created attachment 109600 [details]
Xorg.0.log
Comment 8 Brian Campbell 2014-11-17 08:33:40 UTC
Created attachment 109601 [details]
xrandr --verbose output
Comment 9 Daniel Vetter 2014-11-18 09:51:44 UTC
Please retest with latest drm-intel-nightly from http://cgit.freedesktop.org/drm-intel
Comment 10 Brian Campbell 2014-11-25 12:26:57 UTC
Retested with drm-intel-nightly (after a bit of a detour figuring out why keyboard input didn't work in my initrd in 3.18, preventing me from getting past my disk encryption), results are the same. Any additional info that I can provide?
Comment 11 Brian Campbell 2014-11-26 07:43:25 UTC
After some more testing, I've determined that I can get the full resolution to work, at 30 Hz, with "xrandr --display DP1 --mode 0x47" (in both 3.16 and a build of drm-intel-nightly; I could have sworn I'd tried that before doing this testing, but it seems to be working now).

Using the full 60Hz refresh rate (just letting it auto-detect, or using --mode 3840x1920, or --mode 0x46), I the same error on 3.16 and drm-intel-nightly, with just a slight difference in the exact string. Now the error is:

Nov 25 20:24:13 scratch kernel: [47301.178057] [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* uncleared fifo underrun on pipe A
Nov 25 20:24:13 scratch kernel: [47301.178087] [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun

If it would be useful for me to dump any more information on the drm-intel-nightly kernel, let me know.
Comment 12 Daniel Vetter 2014-11-26 08:08:27 UTC
Well there's nothing really indicating an error (beyond the fifo underrun) in the 3.16 dmesg. Grabbing a new one (with drm.debug=0xe from boot until the mode should be set) can't hurt, but probably won't help.

It really looks like the fifo underrun kills the screen, which usually means the watermarks are bonkers. Which is expected somewhat since we haven't yet tried 4k@60Hz, ever.
Comment 13 Daniel Vetter 2014-11-26 08:12:06 UTC
New idea: Ville's cdclock work might be helpful here.
Comment 14 Ville Syrjala 2014-11-26 08:15:43 UTC
[   26.597300] [drm:intel_ddi_pll_init] CDCLK running at 450000KHz
  3840x2160 (0x46) 533.250MHz +HSync -VSync *current +preferred

533 > 450, so this is never going to work. So like bug 85621, we're going to need to grow these max cdclk checks and filter out such modes.
Comment 15 Brian Campbell 2014-11-26 09:08:31 UTC
Ah, good catch. That's too bad. And I'm assuming there's nothing I can do to reduce blanking even further to get the clock rate down to what's supported? According to the cvt tool, this is the mode for reduced blanking at 3840x2160@60, but there's a relatively new mode for reduced blanking v2 that's supposed to reduce it further still. I don't have access to the relevant standards, however, and can't run the spreadsheet which is public without Excel. I don't know if it's possible that the monitor would support a mode it doesn't advertise, but I figure it's worth a shot. Any idea what the proper modeline for reduced blanking v2 would be, and if it's under 450 MHz?
Comment 16 Anssi Hannula 2014-11-26 10:49:34 UTC
(In reply to Brian Campbell from comment #15)
> I don't know if it's possible that the monitor would support
> a mode it doesn't advertise, but I figure it's worth a shot. Any idea what
> the proper modeline for reduced blanking v2 would be, and if it's under 450
> MHz?

I made up a mode to workaround my issue (bug #85621), but unfortunately 3840x2160@60Hz is not under 450MHz even with no blanking at all:
>>> 3840*2160*60
497664000

You are probably able to take the monitor's original 60Hz mode and just reduce the pixel clock just under 450MHz to achieve 50Hz, though.
>>> 450000000.0/4000/2222
50.63006300630063
Comment 17 Jani Nikula 2015-01-29 15:04:52 UTC
Lumping cdclk bugs together.

*** This bug has been marked as a duplicate of bug 85621 ***
Comment 18 Jari Tahvanainen 2016-10-10 11:34:58 UTC
Closing as duplicate of close+fixed.

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.