Bug 1292596

Summary: gnome-shell freezes upon applying display rotation in gnome-settings > displays
Product: [Fedora] Fedora Reporter: Chris Murphy <bugzilla>
Component: xorg-x11-drv-atiAssignee: X/OpenGL Maintenance List <xgl-maint>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 23CC: airlied, anton4linux, bugzilla, cra, erik, fmuellner, otaylor, rmatos, xgl-maint
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-12-20 17:07:13 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:
Attachments:
Description Flags
dmesg
none
journal
none
dmesg drm.debug=14
none
journal drm.debug=14
none
gdb backtrace gnome-shell 1
none
journal f23 with mesa 10.6.9 none

Description Chris Murphy 2015-12-17 21:13:20 UTC
Description of problem:

In gnome-settings > Displays, clicking on a secondary display, then clicking rotate counter clockwise 90 degree rotation, upon clicking Apply, there is a dialog to keep or revert the change, with a timer, but the entire UI has frozen except the mouse arrow. Clicking on either revert or keep does nothing. The timer isn't timing down. No UI elements respond to any mouse clicks. Reversion doesn't automatically happen after ~ 4 minutes. The session is not recoverable.


Version-Release number of selected component (if applicable):
4.2.8-300.fc23.x86_64
mutter-3.18.2-1.fc23.x86_64
gnome-shell-3.18.3-1.fc23.x86_64
xorg-x11-server-Xorg-1.18.0-2.fc23.x86_64



How reproducible:
Always


Steps to Reproduce:
1. See above
2.
3.

Actual results:

Frozen shell, unrecoverable (systemctl restart gdm works, but everything I was working on in that other environment is now gone)

Expected results:

At worst it should gracefully recover rather than the whole environment effectively dying.

At best it should work, and rotate the display. 


Additional info:

Comment 1 Chris Murphy 2015-12-17 21:13:52 UTC
Created attachment 1106859 [details]
dmesg

Comment 2 Chris Murphy 2015-12-17 21:14:04 UTC
Created attachment 1106860 [details]
journal

Comment 3 Chris Murphy 2015-12-17 21:19:39 UTC
regarding attachment "journal"
External/secondary display NEC PA241W is connect at 13:54, (software) display rotation is applied at 13:55.

Anything after this:
Dec 17 13:56:24 f23m.localdomain systemd[1]: Started Getty on tty3.
is just me dropped to an interface where I can save out dmesg and journal.

Comment 4 Chris Murphy 2015-12-17 21:25:45 UTC
Created attachment 1106874 [details]
dmesg drm.debug=14

Comment 5 Chris Murphy 2015-12-17 21:32:29 UTC
Created attachment 1106875 [details]
journal drm.debug=14

NEC secondary display is connect prior to boot.
Entered gnome settings > Displays at 14:21, chose rotate setting and clicked Apply at 14:22.

Comment 6 Chris Murphy 2015-12-17 21:33:03 UTC
Same problem happens with kernel 4.4.0-rc5.

Comment 7 Rui Matos 2015-12-18 12:43:59 UTC
This happens before you attach the external monitor but it might be related in that it might leave the gpu driver in a state where it can't later recover:

[   14.623058] radeon 0000:01:00.0: evergreen_surface_check_2d:278 texture pitch 1728 invalid must be aligned with 256
[   14.623062] radeon 0000:01:00.0: evergreen_cs_track_validate_texture:827 texture invalid 0x1a3c35c1 0x40000419 0x060a0000 0x00000000 0x80000000 0x800304da
[   14.623079] [drm:radeon_cs_ioctl [radeon]] *ERROR* Invalid command stream !

In any case, if you can switch to a VT, can you attach gdb to your session's gnome-shell process and get us a stack trace while it's stuck like that?

Comment 8 Chris Murphy 2015-12-18 18:38:28 UTC
Created attachment 1107295 [details]
gdb backtrace gnome-shell 1

1. cold boot
2. remotely logged in from another computer
3. gnome-settings > display, rotation applied
4. from remote login, gdb -p 2350, and then backtrace
That whole login to the target computer is what's attached here.

Comment 9 Rui Matos 2015-12-18 18:47:44 UTC
Looks like we're waiting on the X server so yeah it's probably a driver issue. You might want to try different kernels like the previous major release and/or the next and check if it's fixed there.

Comment 10 Chris Murphy 2015-12-19 20:31:55 UTC
The problem does not happen with Fedora 22 Workstation ISO, which uses kernel 4.0.4-301. When I install that same kernel on my otherwise up to date Fedora 23, the problem still occurs, so I don't think it's a kernel regression. And as I mentioned in comment 6, the problem still happens with kernel 4.4.0-rc5.

Comment 11 Chris Murphy 2015-12-19 21:53:35 UTC
The problem also doesn't happen with Fedora 22 as installed, and completely updated, including kernel-4.2.8-300.fc23.x86_64, as originally reported. 

The working installation includes:
mutter-3.16.4-1.fc22.x86_64
gnome-shell-3.16.4-1.fc22.x86_64
xorg-x11-server-Xorg-1.17.4-1.fc22.x86_64

So it seems to me the regression is somewhere other than the kernel.

On the working updated Fedora 22 installation, I still get this message at login time, but it doesn't happen at screen rotation time.

[   13.708768] radeon 0000:01:00.0: evergreen_surface_check_2d:278 texture pitch 3648 invalid must be aligned with 256
[   13.708772] radeon 0000:01:00.0: evergreen_cs_track_validate_texture:827 texture invalid 0x383c71c1 0x400004af 0x060a0000 0x00000000 0x80000000 0x800304da
[   13.708788] [drm:radeon_cs_ioctl [radeon]] *ERROR* Invalid command stream !

Comment 12 Chris Murphy 2015-12-19 23:21:25 UTC
Rotation works with 20151219 build of Workstation (live) ISO on a USB stick.

Comment 13 Charles R. Anderson 2015-12-23 19:49:33 UTC
(In reply to Chris Murphy from comment #10)
> The problem does not happen with Fedora 22 Workstation ISO, which uses
> kernel 4.0.4-301. When I install that same kernel on my otherwise up to date
> Fedora 23, the problem still occurs, so I don't think it's a kernel
> regression. And as I mentioned in comment 6, the problem still happens with
> kernel 4.4.0-rc5.

I have a similar problem with rotation, and I have confirmed that in my instance, the Fedora 23 install with the latest Fedora 22 and Fedora 21 kernels booted does NOT fix the problem.  The Fedora 21 install never had this problem.  So this is another data point that points to it not being a kernel issue, but either a gnome-shell or perhaps mutter issue.

Comment 14 Charles R. Anderson 2015-12-23 19:50:10 UTC
Additionally, Fedora 23 with the F23 kernel does not exhibit lockups with rotation when using a different desktop like XFCE.

Comment 15 Rui Matos 2016-01-04 13:05:22 UTC
Can you try different mesa versions? It should be safe to install fc22 versions on fc23 and vice-versa from http://koji.fedoraproject.org/koji/packageinfo?packageID=184

Comment 16 Chris Murphy 2016-01-05 21:01:14 UTC
mesa-10.6.9-1.20151008.fc22 causes gnome shell to come up with "oh no snap something went wrong" screen, as does mesa-11.2.0-0.devel.3.70d8dbc.fc24. Looks like gdm-wayland fallback is failing. I'll retry with gdm/custom.conf wayland=false.

Comment 17 Chris Murphy 2016-01-05 21:10:23 UTC
Created attachment 1111935 [details]
journal f23 with mesa 10.6.9

gdm on wayland false makes no difference, it still fails to load GDM, so I get no login screen. The journal contains different complaints though than with gdm-wayland, so I'm attaching those. It's the same for mesa 11.2 fc24. So far no mesa f22 or f24 package works with gdm/gnome-session, and so far all the mesa f23 packages cause a hang on rotation.

Comment 18 Charles R. Anderson 2016-01-22 23:30:21 UTC
Stock, updated F23 + lightdm + XFCE == working display rotation with all 4 monitors.

Stock, updated F23 + gdm + Cinnamon desktop == same failure of keyboard/mouse interaction with all 4 monitors rotated.  First I tried manually rotating one monitor, then two monitors, with the buggy Display Settings and there was no mouse/keyboard input failure.  I didn't try more than two manually because I couldn't get the Display Settings panel to work correctly.  As it was, I "accidentally" got the first then the second monitor to rotate.  I had to copy my saved monitors.xml file into ~/.config/ to get the correct set up with all 4 monitors rotated, and then with all 4 monitors rotated I had the same problem as with Gnome.

Stock, updated F23 + gdm + Cinnamon "Software Rendering" desktop == working display rotation with all 4 monitors with the proper monitors.xml (but slow due to software rendering).

Comment 19 Erik del Toro Streb 2016-02-15 22:55:23 UTC
My GPU is AMD HD 3200 integrated graphics.

I can confirm, that when NOT using gdm, e.g. I used the Fedora LXDE spin which uses LXDM as display manager, the problem didn’t appear when I rotated both of my screens.

With the Fedora Workstation spin, which uses gdm as display manager for login, the display freeze happened only for the primary screen. I was able to rotate the secondary screen without any problems. But as soon as I try to rotate the primary screen, the desktop/windows freeze, only mouse cursor stays movable.

After a "systemctl restart gdm" I could login again (but my previous session was lost).

Within the LXDE spin I installed Gnome-Shell with "dnf group install gnome", logged into Gnome-shell and tried to rotate: Same error!

And interesting: In the LXDE spin with installed Gnome-shell, when I login the Gnome-shell and logout again, I see the gdm display manager as greeter.

Linux 4.3.5-300.fc23.x86_64
xorg-x11-server-Xorg 1.18.0.2.fc23.x86_64
mesa 11.1.0
mutter 3.18.2.1.fc23.x86_64
gnome-shell 3.18.3.1.fc23.x86_64

Comment 20 Dave Airlie 2016-02-17 20:46:11 UTC
I pushed an updated xorg-x11-drv-ati to updates-testing can you see if persists?

Comment 21 Chris Murphy 2016-02-18 06:41:47 UTC
So far xorg-x11-drv-ati-7.6.1-3.20160215gitd41fccc.fc23 has fixed the problem in my case.

Comment 22 Erik del Toro Streb 2016-02-18 17:45:14 UTC
Yipee, it works for me, too! Thanks.

Comment 23 Charles R. Anderson 2016-02-18 18:02:50 UTC
xorg-x11-drv-ati-7.6.1-3.20160215gitd41fccc.fc23.x86_64 fixes the freeze/input issue for me too.  Thanks!

Although, I cannot get ~/.config/monitors.xml to apply the rotation automatically anymore.  I have to use this instead after I log in:

#!/bin/sh
xrandr	--output DisplayPort-0 --rotate left --pos 0x0 \
	--output DisplayPort-1 --rotate left --pos 1200x0 \
	--output DisplayPort-2 --rotate left --pos 2400x0 \
	--output DisplayPort-3 --rotate left --pos 3600x0

Comment 24 Charles R. Anderson 2016-02-18 18:09:59 UTC
*** Bug 1288226 has been marked as a duplicate of this bug. ***

Comment 25 Fedora End Of Life 2016-11-24 14:18:39 UTC
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 26 Fedora End Of Life 2016-12-20 17:07:13 UTC
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.