Created attachment 108650 [details] Dmesg with drm-intel-nightly, drm.debug=0x06, modeset at 100sec When trying to set 3440x1440@59.94 on a DP monitor, I get the following messages: [ 494.659559] [drm:ivybridge_set_fifo_underrun_reporting] *ERROR* uncleared fifo underrun on pipe A [ 494.659562] [drm:ivb_err_int_handler] *ERROR* Pipe A FIFO underrun [ 494.659571] [drm:cpt_set_fifo_underrun_reporting] *ERROR* uncleared pch fifo underrun on pch transcoder A [ 494.659572] [drm:cpt_serr_int_handler] *ERROR* PCH transcoder A FIFO underrun and the screen stays blank until I switch back to e.g. 3440x1440@29.97. This happens with stable 3.17 and with current drm-intel-nightly: 2014y-10m-29d-08h-35m-03s. Mainboard: ASUS MAXIMUS V GENE, latest BIOS GPU: 00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller [8086:0162] (rev 09) Attached dmesg with drm.debug=0x06 on drm-intel-nightly, reg dump with a working and non-working mode, vbios dump, Xorg.log, and xrandr --verbose. In the dmesg and Xorg.log, the output is set to 3440x1440@59.94 at 100sec, and to 3440x1440@29.97 at 115sec.
Created attachment 108651 [details] Regdump when on non-working 3440x1440@60.
Created attachment 108652 [details] Regdump when on working 3440x1440@30
Created attachment 108653 [details] VBIOS dump
Created attachment 108654 [details] X.org log, modeset at 100sec
Created attachment 108655 [details] xrandr --verbose
Created attachment 108656 [details] Regdump when on non-working 3440x1440@60 Oops, attached wrong regdump files, reattaching.
Created attachment 108657 [details] Regdump when on working 3440x1440@30
Your dotclock (419.5 MHz) exceeds the core display clock (cdclk) which is 400 MHz on IVB. That means IVB simply can't support this mode as it can't produce pixels fast enough. Unfortunately we lack the necessary checks to reject the mode outright. I've been working on some stuff that should make that possible in the not so distant future. I'll report back when I have something that can be tested.
OK, thanks. As a workaround I reduced the 60Hz mode horizontal blanking period to make the total width 4448px, bringing the mode clock just under 400MHz.
I'm getting the exact same thing on a PR02X docked E7440, which I believe has Haswell GT2. I haven't tried doing 30Hz through the dock yet, but I will. When connecting the 3440x monitor directly to the laptop's mini-DP port, everything works fine at 60Hz. Running 3.18.2, libdrm 2.4.58. Thoughts?
*** This bug has been marked as a duplicate of bug 86478 ***
This is _not_ a dupe of bug 86478
I'm almost sure it is a dup of that. Anssi, please check you can reproduce with any resolution just going to fbcon with ctrl+alt+f2 and going back to X and see if the underrun message is there. I believe there is an error on that irq handle simplification for cpu underrun that is affecting all platforms.
The messages do not trigger if I switch to a fbcon VT and back to X on a working mode. I re-tested and they only appear when setting a non-working high-clock mode (setting a working mode also produces no FIFO overrun messages).
*** Bug 86377 has been marked as a duplicate of this bug. ***
This one is pending Ville's CDCLK series.
(In reply to Jani Nikula from comment #16) > This one is pending Ville's CDCLK series. Does this mean we need a kernel upgrade too for resolution? Or just libdrm?
(In reply to Leho Kraav (:macmaN :lkraav) from comment #17) > (In reply to Jani Nikula from comment #16) > > This one is pending Ville's CDCLK series. > > Does this mean we need a kernel upgrade too for resolution? Or just libdrm? As it is, the kernel does not reject some display modes it should. A kernel upgrade is required (once the patches are done and merged).
(In reply to Jani Nikula from comment #18) > (In reply to Leho Kraav (:macmaN :lkraav) from comment #17) > > (In reply to Jani Nikula from comment #16) > > > This one is pending Ville's CDCLK series. > > > > Does this mean we need a kernel upgrade too for resolution? Or just libdrm? > > As it is, the kernel does not reject some display modes it should. A kernel > upgrade is required (once the patches are done and merged). Mhm thanks. If you don't mind what kernel release is Ville targeting with this stuff? What are the chances of getting backported to LTS kernels? Fortunately as it happens, the 34" LG has a 3440x1440 50Hz rate as native, and 34" DELL has both 50Hz and 60Hz available, allowing for mostly happy camping at 50Hz.
(In reply to Leho Kraav (:macmaN :lkraav) from comment #19) > Mhm thanks. If you don't mind what kernel release is Ville targeting with > this stuff? What are the chances of getting backported to LTS kernels? Best guess v3.21. It was 18 patches at v1, so really no chance of backporting.
Presumed fixed upstream. Please reopen if the problem persists with latest kernels.
I can confirm success on kernel 4.4.4 with up to date everything. Both monitors connected through the dock, which hasn't been possible for a long time. $ [-] xrandr --listmonitors Monitors: 3 0: +eDP1 1920/309x1080/174+0+1440 eDP1 1: +DP1-1 3440/798x1440/335+0+0 DP1-1 2: +DP1-2 1080/509x1920/286+3440+0 DP1-2
Closing resolved+fixed with verification by Leho Kraav.
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.