Bug 1275770
| Summary: | Adding third monitor with i915 crashes Gnome | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Scott Williams <vwfoxguru> | ||||||
| Component: | xorg-x11-server | Assignee: | X/OpenGL Maintenance List <xgl-maint> | ||||||
| Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 23 | CC: | ali+rhbugzilla, awilliam, chris.brown, clarkaddison, david, dschoenb, edoubrayrie, gcarmin, guy.carmin, jan.public, jurikolo, korsnick, kparal, lenz, meverett, negativo17, redhatbugzilla, robatino, sgallagh, vwfoxguru, xgl-maint | ||||||
| Target Milestone: | --- | Keywords: | CommonBugs | ||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | AcceptedFreezeException RejectedBlocker https://fedoraproject.org/wiki/Common_F23_bugs#intel-three-monitors | ||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2016-05-09 15:39:27 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 1170822 | ||||||||
| Attachments: |
|
||||||||
|
Description
Scott Williams
2015-10-27 16:50:21 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. 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. Not sure how to export abrt directly to this ticket, but: https://retrace.fedoraproject.org/faf/reports/863130/ *** Bug 1275784 has been marked as a duplicate of this bug. *** Created attachment 1086959 [details]
/var/log/messages
*** Bug 1275791 has been marked as a duplicate of this bug. *** Created attachment 1086976 [details]
journalctl output
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. 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. David, 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. Scott 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. 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. 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. 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. Just updating to note that the issue persists with same behavior with the xorg updates today. xorg-x11-server-Xorg-1.18.0-0.6.20151027.fc23.x86_64 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. If it's helpful, it's working with this package set: $ rpm -qa xorg* xorg-x11-drv-vmware-13.0.2-8.20150211git8f0cf7c.fc22.x86_64 xorg-x11-server-common-1.18.0-2.fc23.x86_64 xorg-x11-fonts-misc-7.5-15.fc23.noarch xorg-x11-server-Xorg-1.17.4-1.fc22.x86_64 xorg-x11-proto-devel-7.7-16.fc23.noarch xorg-x11-drv-fbdev-0.4.3-20.fc22.x86_64 xorg-x11-utils-7.5-20.fc23.x86_64 xorg-x11-fonts-ISO8859-1-100dpi-7.5-15.fc23.noarch xorg-x11-drv-nouveau-1.0.11-2.fc22.x86_64 xorg-x11-drv-vmmouse-13.0.99-1.fc22.x86_64 xorg-x11-xinit-1.3.4-10.fc23.x86_64 xorg-x11-drv-evdev-2.9.2-1.fc22.x86_64 xorg-x11-xauth-1.0.9-4.fc23.x86_64 xorg-x11-xkb-utils-7.7-16.fc23.x86_64 xorg-x11-drv-wacom-0.29.0-2.fc22.x86_64 xorg-x11-server-Xwayland-1.18.0-2.fc23.x86_64 xorg-x11-drv-intel-2.99.917-15.20150729.fc22.x86_64 xorg-x11-drv-ati-7.5.0-3.fc22.x86_64 xorg-x11-drv-vesa-2.3.2-20.fc22.x86_64 xorg-x11-resutils-7.5-12.fc23.x86_64 xorg-x11-drv-qxl-0.1.3-2.fc22.x86_64 xorg-x11-fonts-Type1-7.5-15.fc23.noarch xorg-x11-font-utils-7.5-29.fc23.x86_64 xorg-x11-drv-v4l-0.2.0-42.fc22.x86_64 xorg-x11-server-utils-7.7-17.fc23.x86_64 xorg-x11-drv-openchrome-0.3.3-14.fc22.x86_64 xorg-x11-drv-synaptics-1.8.2-2.fc22.x86_64 As an update, I tried out the new xorg-x11-server-1.18.0.2 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. 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. 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. See also: bug 1269805 Appears to be addressed in an upstream issue: https://bugs.freedesktop.org/show_bug.cgi?id=89589 Maybe airlied can confirm? Possibly also related to the patch referenced in this thread: https://www.spinics.net/lists/xorg/msg57087.html The same general hardware+symptoms. 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. As an aside, if it's helpful to the maintainer, I added this to the SPEC to get it to build: BuildRequires: libXScrnSaver-devel 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. The issue I originally reported is now fixed as of at least: xorg-x11-server-Xorg-1.18.3-2.fc23.x86_64 xorg-x11-drv-intel-2.99.917-19.20151206.fc23.x86_64 |