Bug 85621

Summary:

[IVB DP] FIFO underrun when trying to set a high display mode

Product:

DRI

Reporter:

Anssi Hannula <anssi>

Component:

DRM/Intel

Assignee:

Intel GFX Bugs mailing list <intel-gfx-bugs>

Status:

CLOSED FIXED

QA Contact:

Intel GFX Bugs mailing list <intel-gfx-bugs>

Severity:

normal

Priority:

medium

CC:

brian.campbell, intel-gfx-bugs, leho

Version:

unspecified

Hardware:

All

OS:

Linux (All)

See Also:

https://bugs.freedesktop.org/show_bug.cgi?id=86377

Whiteboard:

i915 platform:

IVB

i915 features:

display/Other

Attachments:

Description	Flags
Dmesg with drm-intel-nightly, drm.debug=0x06, modeset at 100sec	none
Regdump when on non-working 3440x1440@60.	none
Regdump when on working 3440x1440@30	none
VBIOS dump	none
X.org log, modeset at 100sec	none
xrandr --verbose	none
Regdump when on non-working 3440x1440@60	none
Regdump when on working 3440x1440@30	none

Description Anssi Hannula 2014-10-29 21:16:15 UTC

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.

Comment 1 Anssi Hannula 2014-10-29 21:17:04 UTC

Created attachment 108651 [details]
Regdump when on non-working 3440x1440@60.

Comment 2 Anssi Hannula 2014-10-29 21:17:31 UTC

Created attachment 108652 [details]
Regdump when on working 3440x1440@30

Comment 3 Anssi Hannula 2014-10-29 21:18:01 UTC

Created attachment 108653 [details]
VBIOS dump

Comment 4 Anssi Hannula 2014-10-29 21:18:24 UTC

Created attachment 108654 [details]
X.org log, modeset at 100sec

Comment 5 Anssi Hannula 2014-10-29 21:18:37 UTC

Created attachment 108655 [details]
xrandr --verbose

Comment 6 Anssi Hannula 2014-10-29 21:21:10 UTC

Created attachment 108656 [details]
Regdump when on non-working 3440x1440@60

Oops, attached wrong regdump files, reattaching.

Comment 7 Anssi Hannula 2014-10-29 21:21:40 UTC

Created attachment 108657 [details]
Regdump when on working 3440x1440@30

Comment 8 Ville Syrjala 2014-10-30 08:38:53 UTC

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.

Comment 9 Anssi Hannula 2014-10-30 08:52:26 UTC

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.

Comment 10 Leho Kraav (:macmaN :lkraav) 2015-01-13 21:02:40 UTC

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?

Comment 11 Rodrigo Vivi 2015-01-22 22:23:14 UTC


*** This bug has been marked as a duplicate of bug 86478 ***

Comment 12 Ville Syrjala 2015-01-23 10:02:37 UTC

This is _not_ a dupe of bug 86478

Comment 13 Rodrigo Vivi 2015-01-24 00:55:30 UTC

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.

Comment 14 Anssi Hannula 2015-01-24 05:20:36 UTC

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).

Comment 15 Jani Nikula 2015-01-29 15:04:52 UTC

*** Bug 86377 has been marked as a duplicate of this bug. ***

Comment 16 Jani Nikula 2015-02-12 11:43:03 UTC

This one is pending Ville's CDCLK series.

Comment 17 Leho Kraav (:macmaN :lkraav) 2015-02-12 11:44:36 UTC

(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?

Comment 18 Jani Nikula 2015-02-12 11:54:22 UTC

(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).

Comment 19 Leho Kraav (:macmaN :lkraav) 2015-02-12 12:00:26 UTC

(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.

Comment 20 Jani Nikula 2015-02-12 12:11:35 UTC

(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.

Comment 21 Jani Nikula 2015-10-23 10:17:46 UTC

Presumed fixed upstream. Please reopen if the problem persists with latest kernels.

Comment 22 Leho Kraav (:macmaN :lkraav) 2016-03-06 10:32:54 UTC

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

Comment 23 Jari Tahvanainen 2016-10-10 11:33:21 UTC

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.