Red Hat Bugzilla – Bug 1292596
gnome-shell freezes upon applying display rotation in gnome-settings > displays
Last modified: 2016-12-20 12:07:13 EST
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):
Steps to Reproduce:
1. See above
Frozen shell, unrecoverable (systemctl restart gdm works, but everything I was working on in that other environment is now gone)
At worst it should gracefully recover rather than the whole environment effectively dying.
At best it should work, and rotate the display.
Created attachment 1106859 [details]
Created attachment 1106860 [details]
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: Started Getty on tty3.
is just me dropped to an interface where I can save out dmesg and journal.
Created attachment 1106874 [details]
Created attachment 1106875 [details]
NEC secondary display is connect prior to boot.
Entered gnome settings > Displays at 14:21, chose rotate setting and clicked Apply at 14:22.
Same problem happens with kernel 4.4.0-rc5.
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?
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.
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.
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.
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:
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 !
Rotation works with 20151219 build of Workstation (live) ISO on a USB stick.
(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.
Additionally, Fedora 23 with the F23 kernel does not exhibit lockups with rotation when using a different desktop like XFCE.
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
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.
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.
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).
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.
I pushed an updated xorg-x11-drv-ati to updates-testing can you see if persists?
So far xorg-x11-drv-ati-7.6.1-3.20160215gitd41fccc.fc23 has fixed the problem in my case.
Yipee, it works for me, too! Thanks.
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:
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
*** Bug 1288226 has been marked as a duplicate of this bug. ***
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'
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.
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
Thank you for reporting this bug and we are sorry it could not be fixed.