Hi,
I just got a Lenovo Thinkpad Edge E545 notebook and I have installed Fedora 20/x86_64.
The CPU is Richland A10-5750 (contains ARUBA graphics) and there is also a discrete HAINAN chip with 2GB dedicated memory on the mainboard.
The problems started during installation, it looked like the machine was frozen when using KMS so I had to use VESA during installation.
I was able to install from the network and the latest kernel upgrade is 3.13.3-201.
So, I was happy at first when I removed "nomodeset" and it booted up properly in KMS mode and did so after the first few restarts.
Initially lspci showed both cards. dmesg told me that HAINAN was not posted by the BIOS but the kernel did it and also loaded the firmware into both cards. Xorg used the integrated ARUBA chip only.
Then I looked up info about PRIME and wanted to test it. However, "xrandr --listproviders" showed only one line and "DRI_PRIME=1 glxinfo64 | grep -i renderer" showed that Mesa is using the ARUBA chip regardless of the DRI_PRIME setting. I am sorry, I didn't save the xrandr output, so I can't prove it. Anyway, Xorg.0.log had only traces about the ARUBA, nothing about the discrete chip. Unfortunately, I didn't save neither dmesg nor Xorg.0.log at the time.
The UEFI BIOS has a knob to switch between "Integrated Graphics" and "Switchable Graphics" and switchable was the default. There is another one for "OS detection for Switchable Graphics: enable/disable"
I started playing with the BIOS settings and this was (or was it?) a mistake. (But this is how I discovered that the virtualization enabled/disabled setting in the BIOS is actually reversed and I also need KVM.)
The result of changing to "Integrated Graphics" in the BIOS and changing back to "Switchable Graphics" and toggling the "OS detection" switch to disabled and back to enabled changed the system behavior.
The symptom is that after systemd loaded all the services, the machine doesn't seem to do anything at first sight. The systemd messages are left on the screen but the X greeter (lightdm) doesn't show up. However, the system reacts to the power button and shuts down properly. This was encouraging and on the next boot I tried to ssh into the machine and successfully collect dmesg and Xorg logs.
It turned out that now, when "Switchable Graphics" is active, regardless of the state of "OS detection for Switchable Graphics", Xorg initializes both cards and apparently wants to use the HAINAN to display the X screen but dies in the process:
[zozo@localhost ~]$ ps auxw | grep Xorg root 626 0.0 0.0 209748 4320 ? Ss 08:51 0:00 /usr/bin/abrt-watch-log -F Backtrace /var/log/Xorg.0.log -- /usr/bin/abrt-dump-xorg -xD zozo 1245 0.0 0.0 112680 976 pts/0 S+ 08:56 0:00 grep --color=auto Xorg [zozo@localhost ~]$ ps auxw | grep dm zozo 1247 0.0 0.0 112676 976 pts/0 S+ 08:57 0:00 grep --color=auto dm
Since this is a very new machine it seems footnote 5 from http://wiki.x.org/wiki/RadeonFeature/ applies and the HAINAN chip is not connected to the display output.
So, currently I can only get it to display X when I use the "Integrated Graphics" setting in the BIOS. In this state, the discrete graphics chip doesn't even show up in lspci:
[zozo@localhost ~]$ cat lspci-hainan-disabled 00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Root Complex 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Richland [Radeon HD 8650G] 00:01.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Trinity HDMI Audio Controller 00:04.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Root Port 00:05.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Root Port 00:07.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Root Port 00:10.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller (rev 09) 00:10.1 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller (rev 09) 00:11.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 40) 00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller (rev 11) 00:12.2 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller (rev 11) 00:13.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller (rev 11) 00:13.2 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller (rev 11) 00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 16) 00:14.2 Audio device: Advanced Micro Devices, Inc. [AMD] FCH Azalia Controller (rev 01) 00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 11) 00:14.4 PCI bridge: Advanced Micro Devices, Inc. [AMD] FCH PCI Bridge (rev 40) 00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Function 0 00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Function 1 00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Function 2 00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Function 3 00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Function 4 00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Function 5 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 07) 02:00.0 Network controller: Broadcom Corporation BCM43142 802.11b/g/n (rev 01) 03:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5229 PCI Express Card Reader (rev 01) [zozo@localhost ~]$
[zozo@localhost ~]$ diff -u lspci-hainan-disabled lspci-hainan-active --- lspci-hainan-disabled 2014-02-19 08:50:00.137888540 +0100 +++ lspci-hainan-active 2014-02-19 08:53:23.523601738 +0100 @@ -1,6 +1,7 @@ 00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Root Complex 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Richland [Radeon HD 8650G] 00:01.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Trinity HDMI Audio Controller +00:02.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Root Port 00:04.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Root Port 00:05.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Root Port 00:07.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Root Port @@ -21,6 +22,7 @@ 00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Function 3 00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Function 4 00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Function 5 -01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 07) -02:00.0 Network controller: Broadcom Corporation BCM43142 802.11b/g/n (rev 01) -03:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5229 PCI Express Card Reader (rev 01) +01:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Sun PRO [Radeon HD 8570A/8570M] +02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 07) +03:00.0 Network controller: Broadcom Corporation BCM43142 802.11b/g/n (rev 01) +04:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5229 PCI Express Card Reader (rev 01) [zozo@localhost ~]$
But I would like to have PRIME functional eventually. What xorg.conf magic should I add to achieve it?
I have dmesg and Xorg logs from this new behavior, both with "Integrated" and "Switchable" states if you are interested.
With the previous state after installation (which I didn't save logs from), dmesg matched the new dmesg with "Switchable" set in the BIOS, so both chips are initialized but the Xorg.0.log matched the log from the "Integrated" state, i.e. only RADEON(0) lines were found. Now, with the "Switchable" state, RADEON(0) lines (for ARUBA) and RADEON(G0) lines (for HAINAN) are present.
On second thought, the usage of VESA for installation and then switching to KMS might have caused the mixed behaviour, i.e. that the kernel recognized and initialized both chips but X used only the integrated one. But I don't want to reinstall the system to test this theory.
Let me ask again, in case you accidentally skipped the question above:
I would like to have PRIME functional so I will need to set "Switchable Graphics" in the BIOS. What xorg.conf magic should I add to make it use the ARUBA chip for display but still keep HAINAN active for PRIME?
Is it possible at this time with Fedora 20 at all? Can Mesa/Xorg use both r600g and radeonsi at the same time?
[zozo@localhost ~]$ rpm -q kernel mesa-libGL xorg-x11-server-Xorg kernel-3.13.3-201.fc20.x86_64 mesa-libGL-9.2.5-1.20131220.fc20.x86_64 mesa-libGL-9.2.5-1.20131220.fc20.i686 xorg-x11-server-Xorg-1.14.4-6.fc20.x86_64
Thanks in advance, Zoltán Böszörményi
On Mit, 2014-02-19 at 09:11 +0100, Boszormenyi Zoltan wrote:
On second thought, the usage of VESA for installation and then switching to KMS might have caused the mixed behaviour, i.e. that the kernel recognized and initialized both chips but X used only the integrated one. But I don't want to reinstall the system to test this theory.
I doubt it would make any difference.
Now, with the "Switchable" state, RADEON(0) lines (for ARUBA) and RADEON(G0) lines (for HAINAN) are present.
[...]
I would like to have PRIME functional so I will need to set "Switchable Graphics" in the BIOS. What xorg.conf magic should I add to make it use the ARUBA chip for display but still keep HAINAN active for PRIME?
According to the screen enumeration above, that's already the case.
https://bugs.freedesktop.org/show_bug.cgi?id=69694 may be helpful for troubleshooting the crash.
Can Mesa/Xorg use both r600g and radeonsi at the same time?
Yes, that seems to work fine for others. You may need Mesa 10.1 or newer though.
2014-02-19 10:59 keltezéssel, Michel Dänzer írta:
On Mit, 2014-02-19 at 09:11 +0100, Boszormenyi Zoltan wrote:
On second thought, the usage of VESA for installation and then switching to KMS might have caused the mixed behaviour, i.e. that the kernel recognized and initialized both chips but X used only the integrated one. But I don't want to reinstall the system to test this theory.
I doubt it would make any difference.
Now, with the "Switchable" state, RADEON(0) lines (for ARUBA) and RADEON(G0) lines (for HAINAN) are present.
[...]
I would like to have PRIME functional so I will need to set "Switchable Graphics" in the BIOS. What xorg.conf magic should I add to make it use the ARUBA chip for display but still keep HAINAN active for PRIME?
According to the screen enumeration above, that's already the case.
I see.
https://bugs.freedesktop.org/show_bug.cgi?id=69694 may be helpful for troubleshooting the crash.
I looked at it and the symptoms from comment 17 and comment 19 (blank screen with only the cursor visible) looks like it's very similar to my case. Only when removing the "quiet" kernel command line option, more is left visible on the screen, not just the cursor.
Can Mesa/Xorg use both r600g and radeonsi at the same time?
Yes, that seems to work fine for others. You may need Mesa 10.1 or newer though.
Do you mean mean with Mesa 9.2.5 and Xorg server 1.14.4 in Fedora 20 at this time, it's not possible unless I compile my own llvm-3.5 SVN, Mesa 10.1 or 10.2 GIT and Xorg 1.15 GIT?
I tried to upgrade to rawhide at least in part:
[zozo@localhost ~]$ rpm -q kernel mesa-libGL xorg-x11-server-Xorg llvm-libs kernel-3.13.3-201.fc20.x86_64 mesa-libGL-10.1-0.rc1.20140208.fc21.x86_64 mesa-libGL-10.1-0.rc1.20140208.fc21.i686 xorg-x11-server-Xorg-1.15.0-3.fc21.x86_64 llvm-libs-3.4-4.fc21.x86_64 llvm-libs-3.4-4.fc21.i686
I still get the same problem. Attached is the log from both 1.14.4 (FC20) and 1.15.0 (rawhide), with this change so the timing info is cut off from the beginning of each line to make it easier to produce a diff between the two files:
[zozo@localhost ~]$ cat Xorg.0.log.hainan-active | cut -d ']' -f 2-
Xorg.0.log.hainan-active-no-timing
[zozo@localhost ~]$ cat /var/log/Xorg.0.log | cut -d ']' -f 2-
Xorg.0.log.hainan-active-no-timing-1.15
Best regards, Zoltán Böszörményi
On Mit, 2014-02-19 at 11:56 +0100, Boszormenyi Zoltan wrote:
2014-02-19 10:59 keltezéssel, Michel Dänzer írta:
On Mit, 2014-02-19 at 09:11 +0100, Boszormenyi Zoltan wrote:
Can Mesa/Xorg use both r600g and radeonsi at the same time?
Yes, that seems to work fine for others. You may need Mesa 10.1 or newer though.
Do you mean mean with Mesa 9.2.5 and Xorg server 1.14.4 in Fedora 20 at this time, it's not possible unless I compile my own llvm-3.5 SVN, Mesa 10.1 or 10.2 GIT and Xorg 1.15 GIT?
I don't think Xorg 1.15 is necessary, but it shouldn't hurt either.
Attached is the log from both 1.14.4 (FC20) and 1.15.0 (rawhide), [...]
The log files end abruptly, so we need to see the X server stderr output. Assuming you're using gdm, it should be captured in /var/log/gdm*/:0.log .
2014-02-20 04:20 keltezéssel, Michel Dänzer írta:
On Mit, 2014-02-19 at 11:56 +0100, Boszormenyi Zoltan wrote:
2014-02-19 10:59 keltezéssel, Michel Dänzer írta:
On Mit, 2014-02-19 at 09:11 +0100, Boszormenyi Zoltan wrote:
Can Mesa/Xorg use both r600g and radeonsi at the same time?
Yes, that seems to work fine for others. You may need Mesa 10.1 or newer though.
Do you mean mean with Mesa 9.2.5 and Xorg server 1.14.4 in Fedora 20 at this time, it's not possible unless I compile my own llvm-3.5 SVN, Mesa 10.1 or 10.2 GIT and Xorg 1.15 GIT?
I don't think Xorg 1.15 is necessary, but it shouldn't hurt either.
Attached is the log from both 1.14.4 (FC20) and 1.15.0 (rawhide), [...]
The log files end abruptly, so we need to see the X server stderr output. Assuming you're using gdm, it should be captured in /var/log/gdm*/:0.log .
FC20 has lightdm by default, here's /var/log/lightdm/x-0.log
Thanks, Zoltán
On Don, 2014-02-20 at 06:09 +0100, Boszormenyi Zoltan wrote:
2014-02-20 04:20 keltezéssel, Michel Dänzer írta:
On Mit, 2014-02-19 at 11:56 +0100, Boszormenyi Zoltan wrote:
2014-02-19 10:59 keltezéssel, Michel Dänzer írta:
On Mit, 2014-02-19 at 09:11 +0100, Boszormenyi Zoltan wrote:
Can Mesa/Xorg use both r600g and radeonsi at the same time?
Yes, that seems to work fine for others. You may need Mesa 10.1 or newer though.
Do you mean mean with Mesa 9.2.5 and Xorg server 1.14.4 in Fedora 20 at this time, it's not possible unless I compile my own llvm-3.5 SVN, Mesa 10.1 or 10.2 GIT and Xorg 1.15 GIT?
I don't think Xorg 1.15 is necessary, but it shouldn't hurt either.
Attached is the log from both 1.14.4 (FC20) and 1.15.0 (rawhide), [...]
The log files end abruptly, so we need to see the X server stderr output. Assuming you're using gdm, it should be captured in /var/log/gdm*/:0.log .
FC20 has lightdm by default, here's /var/log/lightdm/x-0.log
[...]
X: ../../../include/privates.h:122: dixGetPrivateAddr: Assertion `key->initialized' failed.
Can you get a backtrace for this assertion failure with gdb? See http://wiki.x.org/wiki/Development/Documentation/ServerDebugging/
2014-02-20 06:47 keltezéssel, Michel Dänzer írta:
On Don, 2014-02-20 at 06:09 +0100, Boszormenyi Zoltan wrote:
2014-02-20 04:20 keltezéssel, Michel Dänzer írta:
On Mit, 2014-02-19 at 11:56 +0100, Boszormenyi Zoltan wrote:
2014-02-19 10:59 keltezéssel, Michel Dänzer írta:
On Mit, 2014-02-19 at 09:11 +0100, Boszormenyi Zoltan wrote:
Can Mesa/Xorg use both r600g and radeonsi at the same time?
Yes, that seems to work fine for others. You may need Mesa 10.1 or newer though.
Do you mean mean with Mesa 9.2.5 and Xorg server 1.14.4 in Fedora 20 at this time, it's not possible unless I compile my own llvm-3.5 SVN, Mesa 10.1 or 10.2 GIT and Xorg 1.15 GIT?
I don't think Xorg 1.15 is necessary, but it shouldn't hurt either.
Attached is the log from both 1.14.4 (FC20) and 1.15.0 (rawhide), [...]
The log files end abruptly, so we need to see the X server stderr output. Assuming you're using gdm, it should be captured in /var/log/gdm*/:0.log .
FC20 has lightdm by default, here's /var/log/lightdm/x-0.log
[...]
X: ../../../include/privates.h:122: dixGetPrivateAddr: Assertion `key->initialized' failed.
Can you get a backtrace for this assertion failure with gdb? See http://wiki.x.org/wiki/Development/Documentation/ServerDebugging/
Here it is. I simply started Xorg from my ssh sesion and got the same assertion failed.
[root@localhost ~]# gdb /usr/bin/Xorg GNU gdb (GDB) Fedora 7.6.50.20130731-19.fc20 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/. For help, type "help". Type "apropos word" to search for commands related to "word". .. Reading symbols from /usr/bin/Xorg...Reading symbols from /usr/lib/debug/usr/bin/Xorg.debug...done. done. (gdb) run Starting program: /usr/bin/Xorg [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1".
X.Org X Server 1.15.0 Release Date: 2013-12-27 X Protocol Version 11, Revision 0 Build Operating System: 3.12.8-300.fc20.x86_64 Current Operating System: Linux localhost.localdomain 3.13.3-201.fc20.x86_64 #1 SMP Fri Feb 14 19:08:32 UTC 2014 x86_64 Kernel command line: BOOT_IMAGE=/vmlinuz-3.13.3-201.fc20.x86_64 root=UUID=61edc6e4-5eb0-4ec6-869c-f80dd5bd1d93 ro vconsole.font=latarcyrheb-sun16 rhgb quiet LANG=hu_HU.UTF-8 Build Date: 18 February 2014 06:25:51AM Build ID: xorg-x11-server 1.15.0-4.fc21 Current version of pixman: 0.32.0 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Thu Feb 20 08:42:04 2014 (==) Using config directory: "/etc/X11/xorg.conf.d" (==) Using system config directory "/usr/share/X11/xorg.conf.d" Initializing built-in extension Generic Event Extension Initializing built-in extension SHAPE Initializing built-in extension MIT-SHM Initializing built-in extension XInputExtension Initializing built-in extension XTEST Initializing built-in extension BIG-REQUESTS Initializing built-in extension SYNC Initializing built-in extension XKEYBOARD Initializing built-in extension XC-MISC Initializing built-in extension XINERAMA Initializing built-in extension XFIXES Initializing built-in extension RENDER Initializing built-in extension RANDR Initializing built-in extension COMPOSITE Initializing built-in extension DAMAGE Initializing built-in extension MIT-SCREEN-SAVER Initializing built-in extension DOUBLE-BUFFER Initializing built-in extension RECORD Initializing built-in extension DPMS Initializing built-in extension Present Initializing built-in extension DRI3 Initializing built-in extension X-Resource Initializing built-in extension XVideo Initializing built-in extension XVideo-MotionCompensation Initializing built-in extension SELinux Initializing built-in extension XFree86-VidModeExtension Initializing built-in extension XFree86-DGA Initializing built-in extension XFree86-DRI Initializing built-in extension DRI2 warning: the debug information found in "/usr/lib/debug//lib64/libwayland-server.so.0.1.0.debug" does not match "/lib64/libwayland-server.so.0" (CRC mismatch).
warning: the debug information found in "/usr/lib/debug/usr/lib64/libwayland-server.so.0.1.0.debug" does not match "/lib64/libwayland-server.so.0" (CRC mismatch).
warning: the debug information found in "/usr/lib/debug//usr/lib64/libwayland-server.so.0.1.0.debug" does not match "/lib64/libwayland-server.so.0" (CRC mismatch).
warning: the debug information found in "/usr/lib/debug/usr/lib64//libwayland-server.so.0.1.0.debug" does not match "/lib64/libwayland-server.so.0" (CRC mismatch).
Loading extension GLX (II) [KMS] Kernel modesetting enabled. (II) [KMS] Kernel modesetting enabled. [tcsetpgrp failed in terminal_inferior: A művelet nem engedélyezett] warning: the debug information found in "/usr/lib/debug//lib64/libstdc++.so.6.0.19.debug" does not match "/lib64/libstdc++.so.6" (CRC mismatch).
warning: the debug information found in "/usr/lib/debug/usr/lib64/libstdc++.so.6.0.19.debug" does not match "/lib64/libstdc++.so.6" (CRC mismatch).
warning: the debug information found in "/usr/lib/debug//usr/lib64/libstdc++.so.6.0.19.debug" does not match "/lib64/libstdc++.so.6" (CRC mismatch).
warning: the debug information found in "/usr/lib/debug/usr/lib64//libstdc++.so.6.0.19.debug" does not match "/lib64/libstdc++.so.6" (CRC mismatch).
[New Thread 0x7fadb91e7700 (LWP 1249)] Xorg: ../../../include/privates.h:122: dixGetPrivateAddr: Assertion `key->initialized' failed.
Program received signal SIGABRT, Aborted. 0x00007fadc165f1c9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); Missing separate debuginfos, use: debuginfo-install elfutils-libelf-0.158-1.fc20.x86_64 expat-2.1.0-7.fc20.x86_64 freetype-2.5.0-4.fc20.x86_64 libX11-1.6.1-1.fc20.x86_64 libXdamage-1.1.4-4.fc20.x86_64 libXext-1.3.2-2.fc20.x86_64 libXfixes-5.0.1-2.fc20.x86_64 libXxf86vm-1.1.3-2.fc20.x86_64 libffi-3.0.13-5.fc20.x86_64 libfontenc-1.1.1-4.fc20.x86_64 libpng-1.6.3-3.fc20.x86_64 libstdc++-4.8.2-7.fc20.x86_64 libwayland-server-1.2.0-3.fc20.x86_64 libxcb-1.10-1.fc21.x86_64 llvm-libs-3.4-4.fc21.x86_64 ncurses-libs-5.9-12.20130511.fc20.x86_64 pcre-8.33-4.fc20.x86_64 xorg-x11-drv-fbdev-0.4.3-15.fc21.x86_64 xorg-x11-drv-modesetting-0.8.0-11.fc21.x86_64 xorg-x11-drv-vesa-2.3.2-15.fc21.x86_64 xz-libs-5.1.2-6alpha.fc20.x86_64 zlib-1.2.8-3.fc20.x86_64 (gdb) bt f #0 0x00007fadc165f1c9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 resultvar = 0 pid = 1245 selftid = 1245 #1 0x00007fadc16608d8 in __GI_abort () at abort.c:89 save_stage = 2 act = {__sigaction_handler = {sa_handler = 0x7fff83c69779, sa_sigaction = 0x7fff83c69779}, sa_mask = {__val = {140384252091930, 5934588, 122, 4294967295, 140384250731139, 4, 140735404212304, 85899345921, 23742704, 4294967295, 0, 0, 0, 21474836480, 140384295694336, 140384252106912}}, sa_flags = 5917779, sa_restorer = 0x5aaa90 <__PRETTY_FUNCTION__.8544>} sigs = {__val = {32, 0 <repeats 15 times>}} #2 0x00007fadc1658126 in __assert_fail_base (fmt=0x7fadc17a98a0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x5a4c53 "key->initialized", file=file@entry=0x5a8dfc "../../../include/privates.h", line=line@entry=122, function=function@entry=0x5aaa90 <__PRETTY_FUNCTION__.8544> "dixGetPrivateAddr") at assert.c:92 str = 0x1db9780 "" total = 4096 #3 0x00007fadc16581d2 in __GI___assert_fail (assertion=assertion@entry=0x5a4c53 "key->initialized", file=file@entry=0x5a8dfc "../../../include/privates.h", line=line@entry=122, function=function@entry=0x5aaa90 <__PRETTY_FUNCTION__.8544> "dixGetPrivateAddr") at assert.c:101 No locals. #4 0x0000000000424f70 in dixGetPrivateAddr (key=<optimized out>, key=<optimized out>, privates=0x169d558) at ../../../include/privates.h:122 No locals. #5 0x00000000004810eb in dixGetPrivateAddr (key=<optimized out>, key=<optimized out>, privates=0x169d558) at xf86cmap.c:239 No locals. #6 dixSetPrivate (val=<optimized out>, key=0x822f80 <CMapScreenKeyRec>, privates=0x169d558) at ../../../include/privates.h:148 No locals. #7 xf86HandleColormaps (pScreen=pScreen@entry=0x169d180, maxColors=maxColors@entry=256, sigRGBbits=10, loadPalette=loadPalette@entry=0x7fadbcd37ea0 <drmmode_load_palette>, setOverscan=setOverscan@entry=0x0, flags=flags@entry=3) at xf86cmap.c:184 pScrn = 0x169c930 pDefMap = 0x0 gamma = 0x1dc98f0 indices = 0x1dc6d70 elements = 1024 #8 0x00007fadbcd3b32c in drmmode_setup_colormap (pScreen=pScreen@entry=0x169d180, pScrn=pScrn@entry=0x169c930) at drmmode_display.c:1990 No locals. #9 0x00007fadbcd370ef in RADEONScreenInit_KMS (pScreen=pScreen@entry=0x169d180, argc=argc@entry=1, argv=argv@entry=0x7fff83c684c8) at radeon_kms.c:1366 pScrn = 0x169c930 info = 0x16ad1a0 subPixelOrder = <optimized out> s = <optimized out> front_ptr = 0x0 ret = <optimized out> #10 0x0000000000438b4d in AddGPUScreen (pfnInit=0x7fadbcd36c60 <RADEONScreenInit_KMS>, argc=argc@entry=1, argv=argv@entry=0x7fff83c684c8) at dispatch.c:3874 i = 0 pScreen = 0x169d180 ret = <optimized out> #11 0x000000000047aa9f in InitOutput (pScreenInfo=pScreenInfo@entry=0x82dd60 <screenInfo>, argc=argc@entry=1, argv=argv@entry=0x7fff83c684c8) at xf86Init.c:886 pScrn = 0x169c930 i = 0 j = <optimized out> k = <optimized out> scr_index = <optimized out> modulelist = <optimized out> optionlist = 0x1689660 screenpix24 = <optimized out> pix24 = <optimized out> pix24From = <optimized out> pix24Fail = 0 autoconfig = <optimized out> sigio_blocked = 0 want_hw_access = <optimized out> configured_device = <optimized out> #12 0x000000000043c52b in dix_main (argc=1, argv=0x7fff83c684c8, envp=<optimized out>) at main.c:200 i = <optimized out> ---Type <return> to continue, or q <return> to quit--- alwaysCheckForInput = {0, 1} #13 0x00007fadc1649e95 in __libc_start_main (main=0x426c60 <main>, argc=1, argv=0x7fff83c684c8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff83c684b8) at libc-start.c:285 result = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, -8312916593553210373, 4353125, 140735404213440, 0, 0, 8312960929561019387, 8356733329127867387}, mask_was_saved = 0}}, priv = { pad = {0x0, 0x0, 0x5a3880 <__libc_csu_init>, 0x7fff83c684c8}, data = {prev = 0x0, cleanup = 0x0, canceltype = 5912704}}} not_first_call = <optimized out> #14 0x0000000000426c8e in _start () No symbol table info available. (gdb)
2014-02-20 08:44 keltezéssel, Boszormenyi Zoltan írta:
2014-02-20 06:47 keltezéssel, Michel Dänzer írta:
On Don, 2014-02-20 at 06:09 +0100, Boszormenyi Zoltan wrote:
2014-02-20 04:20 keltezéssel, Michel Dänzer írta:
On Mit, 2014-02-19 at 11:56 +0100, Boszormenyi Zoltan wrote:
2014-02-19 10:59 keltezéssel, Michel Dänzer írta:
On Mit, 2014-02-19 at 09:11 +0100, Boszormenyi Zoltan wrote:
> Can Mesa/Xorg use both r600g and radeonsi at the same time? Yes, that seems to work fine for others. You may need Mesa 10.1 or newer though.
Do you mean mean with Mesa 9.2.5 and Xorg server 1.14.4 in Fedora 20 at this time, it's not possible unless I compile my own llvm-3.5 SVN, Mesa 10.1 or 10.2 GIT and Xorg 1.15 GIT?
I don't think Xorg 1.15 is necessary, but it shouldn't hurt either.
Attached is the log from both 1.14.4 (FC20) and 1.15.0 (rawhide), [...]
The log files end abruptly, so we need to see the X server stderr output. Assuming you're using gdm, it should be captured in /var/log/gdm*/:0.log .
FC20 has lightdm by default, here's /var/log/lightdm/x-0.log
[...]
X: ../../../include/privates.h:122: dixGetPrivateAddr: Assertion `key->initialized' failed.
Can you get a backtrace for this assertion failure with gdb? See http://wiki.x.org/wiki/Development/Documentation/ServerDebugging/
Here it is. I simply started Xorg from my ssh sesion and got the same assertion failed.
The previous log contained unmatched debuginfo. I have updated everything needed to make the system consistent with the debuginfos using rawhide's Xorg 1.15.
However, it seems that after the assertion fails, the second attempt failed to initialize the discrete chip so only RADEON(0) lines were present in the Xorg.0.log and gdb didn't stop since the server was running.
Then added the Xdbg script from the ServerDebugging link so the system uses that instead of the plain Xorg binary. The result is attached.
Best regards, Zoltán Böszörményi
On Don, 2014-02-20 at 08:44 +0100, Boszormenyi Zoltan wrote:
2014-02-20 06:47 keltezéssel, Michel Dänzer írta:
On Don, 2014-02-20 at 06:09 +0100, Boszormenyi Zoltan wrote:
2014-02-20 04:20 keltezéssel, Michel Dänzer írta:
On Mit, 2014-02-19 at 11:56 +0100, Boszormenyi Zoltan wrote:
2014-02-19 10:59 keltezéssel, Michel Dänzer írta:
On Mit, 2014-02-19 at 09:11 +0100, Boszormenyi Zoltan wrote:
> Can Mesa/Xorg use both r600g and radeonsi at the same time? Yes, that seems to work fine for others. You may need Mesa 10.1 or newer though.
Do you mean mean with Mesa 9.2.5 and Xorg server 1.14.4 in Fedora 20 at this time, it's not possible unless I compile my own llvm-3.5 SVN, Mesa 10.1 or 10.2 GIT and Xorg 1.15 GIT?
I don't think Xorg 1.15 is necessary, but it shouldn't hurt either.
Attached is the log from both 1.14.4 (FC20) and 1.15.0 (rawhide), [...]
The log files end abruptly, so we need to see the X server stderr output. Assuming you're using gdm, it should be captured in /var/log/gdm*/:0.log .
FC20 has lightdm by default, here's /var/log/lightdm/x-0.log
[...]
X: ../../../include/privates.h:122: dixGetPrivateAddr: Assertion `key->initialized' failed.
Can you get a backtrace for this assertion failure with gdb? See http://wiki.x.org/wiki/Development/Documentation/ServerDebugging/
[...]
#0 0x00007fadc165f1c9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007fadc16608d8 in __GI_abort () at abort.c:89 #2 0x00007fadc1658126 in __assert_fail_base (fmt=0x7fadc17a98a0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x5a4c53 "key->initialized", file=file@entry=0x5a8dfc "../../../include/privates.h", line=line@entry=122, function=function@entry=0x5aaa90 <__PRETTY_FUNCTION__.8544> "dixGetPrivateAddr") at assert.c:92 #3 0x00007fadc16581d2 in __GI___assert_fail (assertion=assertion@entry=0x5a4c53 "key->initialized", file=file@entry=0x5a8dfc "../../../include/privates.h", line=line@entry=122, function=function@entry=0x5aaa90 <__PRETTY_FUNCTION__.8544> "dixGetPrivateAddr") at assert.c:101 #4 0x0000000000424f70 in dixGetPrivateAddr (key=<optimized out>, key=<optimized out>, privates=0x169d558) at ../../../include/privates.h:122 #5 0x00000000004810eb in dixGetPrivateAddr (key=<optimized out>, key=<optimized out>, privates=0x169d558) at xf86cmap.c:239 #6 dixSetPrivate (val=<optimized out>, key=0x822f80 <CMapScreenKeyRec>, privates=0x169d558) at ../../../include/privates.h:148 #7 xf86HandleColormaps (pScreen=pScreen@entry=0x169d180, maxColors=maxColors@entry=256, sigRGBbits=10, loadPalette=loadPalette@entry=0x7fadbcd37ea0 <drmmode_load_palette>, setOverscan=setOverscan@entry=0x0, flags=flags@entry=3) at xf86cmap.c:184 #8 0x00007fadbcd3b32c in drmmode_setup_colormap (pScreen=pScreen@entry=0x169d180, pScrn=pScrn@entry=0x169c930) at drmmode_display.c:1990 #9 0x00007fadbcd370ef in RADEONScreenInit_KMS (pScreen=pScreen@entry=0x169d180, argc=argc@entry=1, argv=argv@entry=0x7fff83c684c8) at radeon_kms.c:1366 #10 0x0000000000438b4d in AddGPUScreen (pfnInit=0x7fadbcd36c60 <RADEONScreenInit_KMS>, argc=argc@entry=1, argv=argv@entry=0x7fff83c684c8) at dispatch.c:3874 #11 0x000000000047aa9f in InitOutput (pScreenInfo=pScreenInfo@entry=0x82dd60 <screenInfo>, argc=argc@entry=1, argv=argv@entry=0x7fff83c684c8) at xf86Init.c:886
Hmm, looks like there's confusion about how colormaps are supposed to be handled.
Dave, any ideas?
On Fri, Feb 21, 2014 at 12:25 PM, Michel Dänzer michel@daenzer.net wrote:
On Don, 2014-02-20 at 08:44 +0100, Boszormenyi Zoltan wrote:
2014-02-20 06:47 keltezéssel, Michel Dänzer írta:
On Don, 2014-02-20 at 06:09 +0100, Boszormenyi Zoltan wrote:
2014-02-20 04:20 keltezéssel, Michel Dänzer írta:
On Mit, 2014-02-19 at 11:56 +0100, Boszormenyi Zoltan wrote:
2014-02-19 10:59 keltezéssel, Michel Dänzer írta: > On Mit, 2014-02-19 at 09:11 +0100, Boszormenyi Zoltan wrote: > >> Can Mesa/Xorg use both r600g and radeonsi at the same time? > Yes, that seems to work fine for others. You may need Mesa 10.1 or newer > though. Do you mean mean with Mesa 9.2.5 and Xorg server 1.14.4 in Fedora 20 at this time, it's not possible unless I compile my own llvm-3.5 SVN, Mesa 10.1 or 10.2 GIT and Xorg 1.15 GIT?
I don't think Xorg 1.15 is necessary, but it shouldn't hurt either.
Attached is the log from both 1.14.4 (FC20) and 1.15.0 (rawhide), [...]
The log files end abruptly, so we need to see the X server stderr output. Assuming you're using gdm, it should be captured in /var/log/gdm*/:0.log .
FC20 has lightdm by default, here's /var/log/lightdm/x-0.log
[...]
X: ../../../include/privates.h:122: dixGetPrivateAddr: Assertion `key->initialized' failed.
Can you get a backtrace for this assertion failure with gdb? See http://wiki.x.org/wiki/Development/Documentation/ServerDebugging/
[...]
#0 0x00007fadc165f1c9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007fadc16608d8 in __GI_abort () at abort.c:89 #2 0x00007fadc1658126 in __assert_fail_base (fmt=0x7fadc17a98a0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x5a4c53 "key->initialized", file=file@entry=0x5a8dfc "../../../include/privates.h", line=line@entry=122, function=function@entry=0x5aaa90 <__PRETTY_FUNCTION__.8544> "dixGetPrivateAddr") at assert.c:92 #3 0x00007fadc16581d2 in __GI___assert_fail (assertion=assertion@entry=0x5a4c53 "key->initialized", file=file@entry=0x5a8dfc "../../../include/privates.h", line=line@entry=122, function=function@entry=0x5aaa90 <__PRETTY_FUNCTION__.8544> "dixGetPrivateAddr") at assert.c:101 #4 0x0000000000424f70 in dixGetPrivateAddr (key=<optimized out>, key=<optimized out>, privates=0x169d558) at ../../../include/privates.h:122 #5 0x00000000004810eb in dixGetPrivateAddr (key=<optimized out>, key=<optimized out>, privates=0x169d558) at xf86cmap.c:239 #6 dixSetPrivate (val=<optimized out>, key=0x822f80 <CMapScreenKeyRec>, privates=0x169d558) at ../../../include/privates.h:148 #7 xf86HandleColormaps (pScreen=pScreen@entry=0x169d180, maxColors=maxColors@entry=256, sigRGBbits=10, loadPalette=loadPalette@entry=0x7fadbcd37ea0 <drmmode_load_palette>, setOverscan=setOverscan@entry=0x0, flags=flags@entry=3) at xf86cmap.c:184 #8 0x00007fadbcd3b32c in drmmode_setup_colormap (pScreen=pScreen@entry=0x169d180, pScrn=pScrn@entry=0x169c930) at drmmode_display.c:1990 #9 0x00007fadbcd370ef in RADEONScreenInit_KMS (pScreen=pScreen@entry=0x169d180, argc=argc@entry=1, argv=argv@entry=0x7fff83c684c8) at radeon_kms.c:1366 #10 0x0000000000438b4d in AddGPUScreen (pfnInit=0x7fadbcd36c60 <RADEONScreenInit_KMS>, argc=argc@entry=1, argv=argv@entry=0x7fff83c684c8) at dispatch.c:3874 #11 0x000000000047aa9f in InitOutput (pScreenInfo=pScreenInfo@entry=0x82dd60 <screenInfo>, argc=argc@entry=1, argv=argv@entry=0x7fff83c684c8) at xf86Init.c:886
Hmm, looks like there's confusion about how colormaps are supposed to be handled.
Dave, any ideas?
xf86_crtc_supports_gamma probably stops us from ever getting into that function, but in the case where we have 0 crtcs I could see fallout.
Either fix the DDX to not call colormap handling if we have 0 crtcs and/or fix the server to not install bother with colormaps if we have 0 crtcs.
Dave.
On Thu, Feb 20, 2014 at 9:37 PM, Dave Airlie airlied@gmail.com wrote:
On Fri, Feb 21, 2014 at 12:25 PM, Michel Dänzer michel@daenzer.net wrote:
On Don, 2014-02-20 at 08:44 +0100, Boszormenyi Zoltan wrote:
2014-02-20 06:47 keltezéssel, Michel Dänzer írta:
On Don, 2014-02-20 at 06:09 +0100, Boszormenyi Zoltan wrote:
2014-02-20 04:20 keltezéssel, Michel Dänzer írta:
On Mit, 2014-02-19 at 11:56 +0100, Boszormenyi Zoltan wrote: > 2014-02-19 10:59 keltezéssel, Michel Dänzer írta: >> On Mit, 2014-02-19 at 09:11 +0100, Boszormenyi Zoltan wrote: >> >>> Can Mesa/Xorg use both r600g and radeonsi at the same time? >> Yes, that seems to work fine for others. You may need Mesa 10.1 or newer >> though. > Do you mean mean with Mesa 9.2.5 and Xorg server 1.14.4 in > Fedora 20 at this time, it's not possible unless I compile my own > llvm-3.5 SVN, Mesa 10.1 or 10.2 GIT and Xorg 1.15 GIT? I don't think Xorg 1.15 is necessary, but it shouldn't hurt either.
> Attached is the log from both 1.14.4 (FC20) and 1.15.0 (rawhide), [...] The log files end abruptly, so we need to see the X server stderr output. Assuming you're using gdm, it should be captured in /var/log/gdm*/:0.log .
FC20 has lightdm by default, here's /var/log/lightdm/x-0.log
[...]
X: ../../../include/privates.h:122: dixGetPrivateAddr: Assertion `key->initialized' failed.
Can you get a backtrace for this assertion failure with gdb? See http://wiki.x.org/wiki/Development/Documentation/ServerDebugging/
[...]
#0 0x00007fadc165f1c9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007fadc16608d8 in __GI_abort () at abort.c:89 #2 0x00007fadc1658126 in __assert_fail_base (fmt=0x7fadc17a98a0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x5a4c53 "key->initialized", file=file@entry=0x5a8dfc "../../../include/privates.h", line=line@entry=122, function=function@entry=0x5aaa90 <__PRETTY_FUNCTION__.8544> "dixGetPrivateAddr") at assert.c:92 #3 0x00007fadc16581d2 in __GI___assert_fail (assertion=assertion@entry=0x5a4c53 "key->initialized", file=file@entry=0x5a8dfc "../../../include/privates.h", line=line@entry=122, function=function@entry=0x5aaa90 <__PRETTY_FUNCTION__.8544> "dixGetPrivateAddr") at assert.c:101 #4 0x0000000000424f70 in dixGetPrivateAddr (key=<optimized out>, key=<optimized out>, privates=0x169d558) at ../../../include/privates.h:122 #5 0x00000000004810eb in dixGetPrivateAddr (key=<optimized out>, key=<optimized out>, privates=0x169d558) at xf86cmap.c:239 #6 dixSetPrivate (val=<optimized out>, key=0x822f80 <CMapScreenKeyRec>, privates=0x169d558) at ../../../include/privates.h:148 #7 xf86HandleColormaps (pScreen=pScreen@entry=0x169d180, maxColors=maxColors@entry=256, sigRGBbits=10, loadPalette=loadPalette@entry=0x7fadbcd37ea0 <drmmode_load_palette>, setOverscan=setOverscan@entry=0x0, flags=flags@entry=3) at xf86cmap.c:184 #8 0x00007fadbcd3b32c in drmmode_setup_colormap (pScreen=pScreen@entry=0x169d180, pScrn=pScrn@entry=0x169c930) at drmmode_display.c:1990 #9 0x00007fadbcd370ef in RADEONScreenInit_KMS (pScreen=pScreen@entry=0x169d180, argc=argc@entry=1, argv=argv@entry=0x7fff83c684c8) at radeon_kms.c:1366 #10 0x0000000000438b4d in AddGPUScreen (pfnInit=0x7fadbcd36c60 <RADEONScreenInit_KMS>, argc=argc@entry=1, argv=argv@entry=0x7fff83c684c8) at dispatch.c:3874 #11 0x000000000047aa9f in InitOutput (pScreenInfo=pScreenInfo@entry=0x82dd60 <screenInfo>, argc=argc@entry=1, argv=argv@entry=0x7fff83c684c8) at xf86Init.c:886
Hmm, looks like there's confusion about how colormaps are supposed to be handled.
Dave, any ideas?
xf86_crtc_supports_gamma probably stops us from ever getting into that function, but in the case where we have 0 crtcs I could see fallout.
Either fix the DDX to not call colormap handling if we have 0 crtcs and/or fix the server to not install bother with colormaps if we have 0 crtcs.
Does the attached patch help?
Alex
Dave. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
2014-02-21 14:37 keltezéssel, Alex Deucher írta:
Does the attached patch help?
Alex
Yes, it helped, thank you very much. The compressed Xorg.0.log is attached as proof.
To others: the patch is against xf86-video-ati.
Two notes, though:
1. Is it normal that "xrandr --listproviders" lists 3 providers?
[zozo@localhost ~]$ cat xrandr-providers Providers: number : 3 Provider 0: id: 0x86 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 4 outputs: 3 associated providers: 2 name:radeon Provider 1: id: 0x4f cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 0 outputs: 0 associated providers: 2 name:radeon Provider 2: id: 0x4f cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 0 outputs: 0 associated providers: 2 name:radeon
2. I tried glxgears with and without DRI_PRIME=1 as below:
[zozo@localhost ~]$ glxgears Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 299 frames in 5.0 seconds = 59.558 FPS [zozo@localhost ~]$ DRI_PRIME=1 glxgears Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 5589 frames in 5.0 seconds = 1117.730 FPS 5369 frames in 5.0 seconds = 1073.715 FPS 5699 frames in 5.0 seconds = 1139.670 FPS
Obviously, it doesn't sync to the framerate with PRIME. On the other hand, nothing is displayed in the glxgears window. I have llvm 3.4-4 and Mesa 10.1-rc1 from Fedora 21 rawhide.
I will go back to plain Fedora 20 (Xorg 1.14, llvm 3.3 and Mesa 9.2.5) and try the same patch to see if there's any difference.
Best regards, Zoltán Böszörményi
2014-02-21 15:32 keltezéssel, Boszormenyi Zoltan írta:
2014-02-21 14:37 keltezéssel, Alex Deucher írta:
Does the attached patch help?
Alex
Yes, it helped, thank you very much. The compressed Xorg.0.log is attached as proof.
To others: the patch is against xf86-video-ati.
Two notes, though:
- Is it normal that "xrandr --listproviders" lists 3 providers?
[zozo@localhost ~]$ cat xrandr-providers Providers: number : 3 Provider 0: id: 0x86 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 4 outputs: 3 associated providers: 2 name:radeon Provider 1: id: 0x4f cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 0 outputs: 0 associated providers: 2 name:radeon Provider 2: id: 0x4f cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 0 outputs: 0 associated providers: 2 name:radeon
- I tried glxgears with and without DRI_PRIME=1 as below:
[zozo@localhost ~]$ glxgears Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 299 frames in 5.0 seconds = 59.558 FPS [zozo@localhost ~]$ DRI_PRIME=1 glxgears Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 5589 frames in 5.0 seconds = 1117.730 FPS 5369 frames in 5.0 seconds = 1073.715 FPS 5699 frames in 5.0 seconds = 1139.670 FPS
Obviously, it doesn't sync to the framerate with PRIME. On the other hand, nothing is displayed in the glxgears window. I have llvm 3.4-4 and Mesa 10.1-rc1 from Fedora 21 rawhide.
I will go back to plain Fedora 20 (Xorg 1.14, llvm 3.3 and Mesa 9.2.5) and try the same patch to see if there's any difference.
With Fedora 20 packages X doesn't come up. The last message on the screen is:
[ 19.016881] pci_pm_runtime_suspend(): radeon_pmops_runtime_suspend+0x0/0xa0 [radeon] return -22
Xorg crashes and Xorg.0.log now contains the backtrace, attached.
Best regards, Zoltán Böszörményi
On Fri, Feb 21, 2014 at 9:32 AM, Boszormenyi Zoltan zboszor@pr.hu wrote:
2014-02-21 14:37 keltezéssel, Alex Deucher írta:
Does the attached patch help?
Alex
Yes, it helped, thank you very much. The compressed Xorg.0.log is attached as proof.
To others: the patch is against xf86-video-ati.
Two notes, though:
- Is it normal that "xrandr --listproviders" lists 3 providers?
[zozo@localhost ~]$ cat xrandr-providers Providers: number : 3 Provider 0: id: 0x86 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 4 outputs: 3 associated providers: 2 name:radeon Provider 1: id: 0x4f cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 0 outputs: 0 associated providers: 2 name:radeon Provider 2: id: 0x4f cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 0 outputs: 0 associated providers: 2 name:radeon
- I tried glxgears with and without DRI_PRIME=1 as below:
[zozo@localhost ~]$ glxgears Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 299 frames in 5.0 seconds = 59.558 FPS [zozo@localhost ~]$ DRI_PRIME=1 glxgears Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 5589 frames in 5.0 seconds = 1117.730 FPS 5369 frames in 5.0 seconds = 1073.715 FPS 5699 frames in 5.0 seconds = 1139.670 FPS
Obviously, it doesn't sync to the framerate with PRIME. On the other hand, nothing is displayed in the glxgears window. I have llvm 3.4-4 and Mesa 10.1-rc1 from Fedora 21 rawhide.
Make sure you are running a compositor.
Alex
2014-02-21 16:12 keltezéssel, Alex Deucher írta:
On Fri, Feb 21, 2014 at 9:32 AM, Boszormenyi Zoltan zboszor@pr.hu wrote:
[zozo@localhost ~]$ DRI_PRIME=1 glxgears Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 5589 frames in 5.0 seconds = 1117.730 FPS 5369 frames in 5.0 seconds = 1073.715 FPS 5699 frames in 5.0 seconds = 1139.670 FPS
Obviously, it doesn't sync to the framerate with PRIME. On the other hand, nothing is displayed in the glxgears window. I have llvm 3.4-4 and Mesa 10.1-rc1 from Fedora 21 rawhide.
Make sure you are running a compositor.
Turning on compositing in MATE fixed it. Thank you very much. It seems I will have to keep Rawhide on this notebook. :-)
Best regards, Zoltán Böszörményi
dri-devel@lists.freedesktop.org
-
Alex Deucher -
Boszormenyi Zoltan -
Dave Airlie -
Michel Dänzer