Bug 91417

Summary: xorg crashes/locks up on screen orientation change
Product: xorg Reporter: Ben Copeland <ben.comobile>
Component: Driver/RadeonAssignee: xf86-video-ati maintainers <xorg-driver-ati>
Status: RESOLVED MOVED QA Contact: Xorg Project Team <xorg-team>
Severity: major    
Priority: high CC: ben.comobile
Version: git   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
arandr screen orientation 1
none
arandr screen orientation 2
none
xorg error output
none
current xorg output
none
attachment-7912-0.html
none
strace output after screen orientation change
none
xorg in verbose 6 from boot. none

Description Ben Copeland 2015-07-21 22:17:14 UTC
Created attachment 117284 [details]
arandr screen orientation 1

AMD/ATI Hawaii PRO [Radeon R9 290]



1) Steps to Reproduce: change screen orientation to any position other than landscape (or all the same) causes xorg to crash. 

[   263.650] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[   263.650] (++) using VT number 1

[   263.650] (II) [KMS] Kernel modesetting enabled.
[   263.650] (WW) Falling back to old probe method for modesetting
[   263.650] (II) RADEON(0): Creating default Display subsection in Screen section
	"Default Screen Section" for depth/fbbpp 24/32
[   263.650] (==) RADEON(0): Depth 24, (--) framebuffer bpp 32
[   263.650] (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps)
[   263.650] (==) RADEON(0): Default visual is TrueColor
[   263.650] (==) RADEON(0): RGB weight 888
[   263.650] (II) RADEON(0): Using 8 bits per RGB (8 bit DAC)
[   263.650] (--) RADEON(0): Chipset: "HAWAII" (ChipID = 0x67b1)
[   263.651] (EE) RADEON(0): [drm] failed to set drm interface version.
[   263.651] (EE) RADEON(0): Kernel modesetting setup failed
[   263.651] (II) UnloadModule: "radeon"
[   263.651] (EE) Screen(s) found, but none have a usable configuration.
[   263.651] (EE) 
Fatal server error:
[   263.651] (EE) no screens found(EE) 
[   263.651] (EE) 
Please consult the The X.Org Foundation support 
	 at http://wiki.x.org
 for help. 
[   263.651] (EE) Please also check the log file at "/var/log/Xorg.1.log" for additional information.
[   263.651] (EE) 
[   263.654] (EE) Server terminated with error (1). Closing log file.
Comment 1 Ben Copeland 2015-07-21 22:17:41 UTC
Created attachment 117285 [details]
arandr screen orientation 2
Comment 2 Ben Copeland 2015-07-21 22:18:08 UTC
Created attachment 117286 [details]
xorg error output
Comment 3 Ben Copeland 2015-07-21 22:18:28 UTC
Created attachment 117287 [details]
current xorg output
Comment 4 Ben Copeland 2015-07-21 22:20:47 UTC
Name           : xf86-video-ati
Version        : 1:7.5.0-2
Comment 5 Alex Deucher 2015-07-21 22:24:20 UTC
According to your log X seems to have failed to start altogether.  How are you changing the orientation if X is not even running?
Comment 6 Ben Copeland 2015-07-21 22:53:32 UTC
Created attachment 117288 [details]
attachment-7912-0.html

X runs fine when I have all the screens in landscape mode. It crashes when
I change screen orientation.

Lightdm boots my landscape setup from a xrandr script.

On Tue, 21 Jul 2015 23:24  <bugzilla-daemon@freedesktop.org> wrote:

>   *Comment # 5 <https://bugs.freedesktop.org/show_bug.cgi?id=91417#c5> on
> bug 91417 <https://bugs.freedesktop.org/show_bug.cgi?id=91417> from Alex
> Deucher <alexdeucher@gmail.com> *
>
> According to your log X seems to have failed to start altogether.  How are you
> changing the orientation if X is not even running?
>
>  ------------------------------
> You are receiving this mail because:
>
>    - You are on the CC list for the bug.
>    - You reported the bug.
>
>
Comment 7 Alex Deucher 2015-07-22 02:58:33 UTC
What do you mean by crash?  Segfault?  Hang?  Can you get a log from the crash or a backtrace?  Does it crash the same way if you manually adjust the screens with xrandr?
Comment 8 Ben Copeland 2015-07-24 08:40:33 UTC
So I booted my machine up and ran my normal xrandr command to set the monitors up (1). I started x in verbose mode, I then proceeded to change orientation of one monitor, this caused the other monitors to crash. I can see a picture still, and the mouse curse can move across it. I can from what it seems launch programs in the said monitors, but the clock doesn't update and nothing is actually outputted. So its good as dead.

xorg, process does seem to be going nuts. I did a strace output and have attached both the log and strace to the bug. 

I have also noticed, if I put HDMI-0 (end screen on attached image) in portrait mode, I get a similar crash. However if I put HDMI-0 "under" dvi-1, its fine...
Comment 9 Ben Copeland 2015-07-24 08:42:37 UTC
Created attachment 117337 [details]
strace output after screen orientation change
Comment 10 Ben Copeland 2015-07-24 08:43:16 UTC
Created attachment 117338 [details]
xorg in verbose 6 from boot.
Comment 11 Ben Copeland 2015-07-24 08:44:15 UTC
Sorry, missed the command out of email.

(1)
xrandr --output DisplayPort-0 --mode 1920x1080 --pos 0x1080 --rotate normal --output DVI-1 --mode 2560x1600 --primary --pos 1920x272 --rotate normal --output DVI-0 --mode 1920x1080 --pos 0x0 --rotate normal --output HDMI-0 --mode 1920x1080 --pos 4480x504 --rotate normal
Comment 12 Ben Copeland 2015-07-24 08:46:21 UTC
Because bugzilla has a 3mb limit I have pasted the complete strace log on gist.

https://gist.github.com/anonymous/37c0b3e22d0fb8a1f42b
Comment 13 Michel Dänzer 2018-05-30 07:36:10 UTC
Is this still an issue with current versions of xf86-video-ati, xserver, Mesa and the kernel?
Comment 14 Martin Peres 2019-11-19 07:51:20 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/issues/134.

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.