Bug 1275770 - Adding third monitor with i915 crashes Gnome
Summary: Adding third monitor with i915 crashes Gnome
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-server
Version: 23
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact: Fedora Extras Quality Assurance
Whiteboard: AcceptedFreezeException RejectedBlock...
: 1275784 1275791 (view as bug list)
Depends On:
Blocks: F23FinalFreezeException
TreeView+ depends on / blocked
Reported: 2015-10-27 16:50 UTC by Scott Williams
Modified: 2016-05-23 20:35 UTC (History)
21 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2016-05-09 15:39:27 UTC
Type: Bug

Attachments (Terms of Use)
/var/log/messages (658.02 KB, text/plain)
2015-10-27 18:14 UTC, Scott Williams
no flags Details
journalctl output (2.19 MB, text/plain)
2015-10-27 18:31 UTC, Scott Williams
no flags Details

System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1256712 0 unspecified CLOSED System freezes after login when monitor is connected to docking station of laptop 2021-02-22 00:41:40 UTC

Internal Links: 1256712

Description Scott Williams 2015-10-27 16:50:21 UTC
Description of problem:
In Fedora 22, I ran a three monitor setup via Dell docking station.  The laptop has optimus enabled as the nvidia card only supports 2 outputs where the intel supports three.  Since upgrading to Fedora 23, I can only get output from the laptop screen and one external monitor.  In the Displays tool, Gnome sees the third monitor, but enabling it causes Gnome to crash.

Attempting this with xrandr shows an an error "crtc 5 failed".  If I simply do 'xrandr --auto' it enables the third monitor at full resolution but then mirrors it to the first display.

As such, I have no way to get the same functionality I had with this setup in Fedora 22, which worked simply via the Gnome Displays tool.  

Because this laptop has Optimus, disabling Optimus, brings me down to 2 displays max due to limits on nVidia card.  I do not have the nvidia binary or bumblebee installed - only FOSS drivers.

Version-Release number of selected component (if applicable):
Fedora 23 
kernel: 4.2.3-300.fc23.x86_64

How reproducible:

Steps to Reproduce:
1. Add 2 external monitors to Dell dock with Optimus
2. Login to Gnome session
3. Attempt to enable third monitor as "Secondary"
4. Observe the ensuing crashy spectacle
- For best results rinse and repeat, Gnome fully becomes unresponsive after about 3 tries

Actual results:
Only two monitors can be enabled, with the laptop screen being one of them.

Expected results:
External monitors work as advertised in the Display tool, as supported by the hardware.  In other words, how it worked exactly in Fedora 22.

Additional info:
$ xrandr -q
Screen 0: minimum 320 x 200, current 3840 x 1200, maximum 8192 x 8192
LVDS-1 connected (normal left inverted right x axis y axis)
   1920x1080     60.01 +  40.01  
   1680x1050     59.95  
   1400x1050     59.98  
   1280x1024     59.89  
   1280x960      59.94  
   1152x864      59.96  
   1024x768      59.92  
   800x600       59.86  
   640x480       59.38  
   720x400       59.55  
   640x400       59.95  
   640x350       59.77  
DP-1 connected primary 1920x1200+0+0 (normal left inverted right x axis y axis) 518mm x 324mm
   1920x1200     59.95*+
   1920x1080     60.00  
   1600x1200     60.00  
   1680x1050     59.88  
   1280x1024     60.02  
   1280x960      60.00  
   1024x768      60.00  
   800x600       60.32  
   640x480       60.00  
   720x400       70.08  
DP-2 connected 1920x1200+1920+0 (normal left inverted right x axis y axis) 519mm x 324mm
   1920x1200     59.95*+
   1600x1200     60.00  
   1680x1050     59.88  
   1280x1024     75.02    60.02  
   1152x864      75.00  
   1024x768      75.08    60.00  
   800x600       75.00    60.32  
   640x480       75.00    60.00  
   720x400       70.08  
HDMI-1 disconnected (normal left inverted right x axis y axis)
VGA-1 disconnected (normal left inverted right x axis y axis)

Comment 1 Fedora Blocker Bugs Application 2015-10-27 16:58:39 UTC
Proposed as a Blocker for 23-final by Fedora user vwbusguy using the blocker tracking app because:

 Severe regression that can crash Gnome entirely.  Limits productivity for regular workstation functional use.

Comment 2 Scott Williams 2015-10-27 17:30:55 UTC
For clarification based on IRC conversation in #Fedora-QA:

* Two monitors is still a problem.  I cannot simply enable the two extarnal monitors and disable the laptop screen.  The laptop screen stays enabled even if the lid is closed.  

* The reason this is a blocker request is that the basic usage of the GUI tool causes an outright DE crash.  To that extent alone, the "third monitor" is irrelevant.  

* This has nothing directly to do with Optimus.  Bumblebee is not installed, nor being used.  I only mentioned it to demonstrate the hardware situation.  Optimus continues to work as far as I've been able to test so far.  This is an Intel i915 related issue and not related to nouveau.

* This worked out of the box in Fedora 22.

Comment 3 Scott Williams 2015-10-27 17:59:22 UTC
Not sure how to export abrt directly to this ticket, but: https://retrace.fedoraproject.org/faf/reports/863130/

Comment 4 Scott Williams 2015-10-27 18:02:19 UTC
*** Bug 1275784 has been marked as a duplicate of this bug. ***

Comment 5 Scott Williams 2015-10-27 18:03:14 UTC

Comment 6 Scott Williams 2015-10-27 18:14:45 UTC
Created attachment 1086959 [details]

Comment 7 Scott Williams 2015-10-27 18:21:01 UTC
*** Bug 1275791 has been marked as a duplicate of this bug. ***

Comment 8 Scott Williams 2015-10-27 18:31:08 UTC
Created attachment 1086976 [details]
journalctl output

Comment 9 Stephen Gallagher 2015-10-28 02:03:34 UTC
I'm +1 FE to this, but while this is unfortunate, I don't think it specifically violates any blocker criterion that I can find.

It's *fuzzy* on:

"All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test... Basic functionality means that the app must at least be broadly capable of its most basic expected operations, and that it must not crash without user intervention or with only basic user intervention."

I say fuzzy because it doesn't cause a specific app to fail. If you run the system with only a basic hardware configuration (the built-in monitor), things run successfully, which to me meets the "basic user intervention" criteria.

So I'm a weak -1 blocker on this due to it being hardware-specific. I think that this is one of those cases where if it was the last blocker on the list, we likely wouldn't slip over it, which pretty much defines "not a blocker" to me.

Comment 10 David Strauss 2015-10-28 06:05:37 UTC
I experience plenty of crashes of GNOME on Fedora 22 with two chained DisplayPort MST displays, which is also how many docking stations now work. So, I don't see how this is a substantial regression versus the current release.

Comment 11 Scott Williams 2015-10-28 14:30:00 UTC

I can't comment on your hardware.  There are many vendor variances in docking stations, however, this setup has worked without issue in Fedora 22 and 21 until the 23 upgrade.


Comment 12 Scott Williams 2015-10-28 14:41:09 UTC
If it's helpful, this is from Dell's business lineup: Dell Latitude E6530 with 2 24" Dell monitors connected via DVI.  This isn't just some random commodity hardware, but this is a pretty common business setup offering from Dell.

Again, this is not using proprietary drivers or bumblebee.

Comment 13 Kamil Páral 2015-10-29 14:44:33 UTC
Since kernel 4.2, I also see issues with three monitors. I described them in bug 1256712 comment 13. Most of them are not crashes, but not waking up or forgetting display configuration. I see no crashes when using gnome-control-center to configure them. I have a single intel card in T450s. Lukas Brabec sees similar issues (same hardware). There seem to be severe regressions in the intel driver in the latest kernels.

Comment 14 Scott Williams 2015-10-29 19:14:02 UTC
I was not experiencing this on the latest Fedora 22 kernel, however, if I boot to the Fedora 22 kernel in Fedora 23, the issue still occurs, which means I don't think this is necessarily a kernel problem, but perhaps an xrandr or Gnome problem.

Comment 15 Adam Williamson 2015-10-29 23:37:02 UTC
Discussed at 2015-10-29 Go/No-Go meeting, acting as a blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-meeting-2/2015-10-29/f23-final-go_no_go-meeting_2.2015-10-29-16.00.html . Rejected as a blocker: this was considered to be likely some kind of hardware-specific issue and not to really constitute 'basic functionality' of the GNOME Control Center. Accepted as a freeze exception issue.

Comment 16 Scott Williams 2015-11-03 20:32:36 UTC
Just updating to note that the issue persists with same behavior with the xorg updates today.


Comment 17 Scott Williams 2015-12-01 00:22:20 UTC
I upgraded to 4.2.6 today and still noticed the same issues.  On a whim, I downgraded to xorg-1.17 via dnf --releasever=22 and everything works again.  It's clearly an issue with the xorg server update.  All three monitors work fine otherwise on kernel 4.2.6 with Xorg-1.17.

Comment 18 Scott Williams 2015-12-01 00:25:16 UTC
If it's helpful, it's working with this package set:

$ rpm -qa xorg*

Comment 19 Scott Williams 2015-12-14 19:15:57 UTC
As an update, I tried out the new xorg-x11-server- and xorg-x11-drv-intel 2.99.917-18.  The experience is now even more degraded.  

With multiple monitors, one of the external is turned on but cannot actually be accessed - it just shows the GDM background.  The laptop monitor is turned on, but the graphics are badly distorted with mouse trails and artifacts making even resizing a window or copy/paste a tedious and painful experience.

Again, regressing to the xorg server shipped in F22 removes all these issues.

Comment 20 Scott Williams 2015-12-14 19:18:46 UTC
Since there hasn't been any response from the package maintainers, I'm wondering if there's any more information I can possibly provide to help?  I've provided a good amount of testing and details here and am wondering if it's worth any more effort on my part to report on this.

Comment 21 Jan Vlug 2015-12-15 15:39:15 UTC
I confirm that I have similar issues as Scott on an HP docking station with two external monitors and the laptop monitor.
I could also provide more detailed information if that is of any use for determining the root cause of the three monitor setups.

Comment 22 Jan Vlug 2015-12-15 15:42:13 UTC
See also: bug 1269805

Comment 23 Scott Williams 2016-01-05 00:57:27 UTC
Appears to be addressed in an upstream issue: https://bugs.freedesktop.org/show_bug.cgi?id=89589

Maybe airlied can confirm?

Comment 24 Scott Williams 2016-01-05 01:03:41 UTC
Possibly also related to the patch referenced in this thread: https://www.spinics.net/lists/xorg/msg57087.html 

The same general hardware+symptoms.

Comment 25 Scott Williams 2016-01-05 20:28:16 UTC
I compiled a new RPM from the current xf86-video-intel master branch as there are some relevant recent commits, but still seeing the same issues from original report.

Note that everything works with the current f23 kernel (4.2.8-300) and downgraded xorg server/driver from f22.

The issue seems to be how xrandr and the driver are interacting with crtc's for i915.

Comment 26 Scott Williams 2016-01-05 20:30:03 UTC
As an aside, if it's helpful to the maintainer, I added this to the SPEC to get it to build:

BuildRequires: libXScrnSaver-devel

Comment 27 Lenz Grimmer 2016-01-08 13:04:41 UTC
FWIW, I'm experiencing similar issues with FC32 on a ThinkPad T440s (using an "Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 0b)" according to "lspci"), connected to a Lenovo UltraDock. I use the laptop with the lid closed and two monitors connected to the docking station (one via DVI, the other via analog VGA).

Very often, the second external monitor connected to the VGA port does not resume after the screen blanker has put the monitors into power-saving mode.

In "dmesg", I see the following message:

[176394.553305] [drm:check_crtc_state [i915]] *ERROR* mismatch in ips_enabled (expected 1, found 0)

Disabling and enabling the monitor via xrandr brings it back to life, but this is somewhat inconvenient. If there is any update package I could help testing, I'd be glad to.

Comment 28 Scott Williams 2016-05-09 15:39:27 UTC
The issue I originally reported is now fixed as of at least:


Note You need to log in before you can comment on or make changes to this bug.