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
Created attachment 109594 [details] cat /proc/cpuinfo
Created attachment 109595 [details] Ouptut of dmesg
Created attachment 109596 [details] Ouptut of dmidecode
Created attachment 109597 [details] Output of intel_reg_dumper
Created attachment 109598 [details] Output of lspci -v
Created attachment 109599 [details] vbios dump
Created attachment 109600 [details] Xorg.0.log
Created attachment 109601 [details] xrandr --verbose output
Please retest with latest drm-intel-nightly from http://cgit.freedesktop.org/drm-intel
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?
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.
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.
New idea: Ville's cdclock work might be helpful here.
[ 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.
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?
(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
Lumping cdclk bugs together. *** This bug has been marked as a duplicate of bug 85621 ***
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.