AMD/AMD hybrid graphics

Commit Message

Zoltán Böszörményi Feb. 19, 2014, 8:11 a.m. UTC

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
  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

Comments

Michel Dänzer Feb. 19, 2014, 9:59 a.m. UTC | #1

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.

Zoltán Böszörményi Feb. 19, 2014, 10:56 a.m. UTC | #2

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

Michel Dänzer Feb. 20, 2014, 3:20 a.m. UTC | #3

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 .

Zoltán Böszörményi Feb. 20, 2014, 5:09 a.m. UTC | #4

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

Michel Dänzer Feb. 20, 2014, 5:47 a.m. UTC | #5

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/

Zoltán Böszörményi Feb. 20, 2014, 7:44 a.m. UTC | #6

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)

Zoltán Böszörményi Feb. 20, 2014, 8:17 a.m. UTC | #7

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
[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 09:09:35 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
Loading extension GLX
(II) [KMS] Kernel modesetting enabled.
(II) [KMS] Kernel modesetting enabled.
[tcsetpgrp failed in terminal_inferior: A m?velet nem engedélyezett]
Xorg.orig: ../../../include/privates.h:122: dixGetPrivateAddr: Assertion `key->initialized' failed.
[New Thread 0x7fd2bdfbf700 (LWP 1349)]

Program received signal SIGABRT, Aborted.
0x00007fd2c643f1c9 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);
#0  0x00007fd2c643f1c9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
        resultvar = 0
        pid = 1345
        selftid = 1345
#1  0x00007fd2c64408d8 in __GI_abort () at abort.c:89
        save_stage = 2
        act = {__sigaction_handler = {sa_handler = 0x7fffc19f6768, sa_sigaction = 0x7fffc19f6768}, sa_mask = {__val = {140543247539738, 5934588, 122, 4294967295, 140543246178947, 4, 
              140736441829952, 85899345921, 31447312, 4294967295, 0, 0, 0, 21474836480, 140543291142144, 140543247554720}}, sa_flags = 5917779, 
          sa_restorer = 0x5aaa90 <__PRETTY_FUNCTION__.8544>}
        sigs = {__val = {32, 0 <repeats 15 times>}}
#2  0x00007fd2c6438126 in __assert_fail_base (fmt=0x7fd2c65898a0 "%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 = 0x251bd20 ""
        total = 4096
#3  0x00007fd2c64381d2 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=0x1df6578) at ../../../include/privates.h:122
No locals.
#5  0x00000000004810eb in dixGetPrivateAddr (key=<optimized out>, key=<optimized out>, privates=0x1df6578) at xf86cmap.c:239
No locals.
#6  dixSetPrivate (val=<optimized out>, key=0x822f80 <CMapScreenKeyRec>, privates=0x1df6578) at ../../../include/privates.h:148
No locals.
#7  xf86HandleColormaps (pScreen=pScreen@entry=0x1df61a0, maxColors=maxColors@entry=256, sigRGBbits=10, loadPalette=loadPalette@entry=0x7fd2c1b0fea0 <drmmode_load_palette>, 
    setOverscan=setOverscan@entry=0x0, flags=flags@entry=3) at xf86cmap.c:184
        pScrn = 0x1df5950
        pDefMap = 0x0
        gamma = 0x2522a70
        indices = 0x2528870
        elements = 1024
#8  0x00007fd2c1b1332c in drmmode_setup_colormap (pScreen=pScreen@entry=0x1df61a0, pScrn=pScrn@entry=0x1df5950) at drmmode_display.c:1990
No locals.
#9  0x00007fd2c1b0f0ef in RADEONScreenInit_KMS (pScreen=pScreen@entry=0x1df61a0, argc=argc@entry=1, argv=argv@entry=0x7fffc19f4eb8) at radeon_kms.c:1366
        pScrn = 0x1df5950
        info = 0x1e061c0
        subPixelOrder = <optimized out>
        s = <optimized out>
        front_ptr = 0x0
        ret = <optimized out>
#10 0x0000000000438b4d in AddGPUScreen (pfnInit=0x7fd2c1b0ec60 <RADEONScreenInit_KMS>, argc=argc@entry=1, argv=argv@entry=0x7fffc19f4eb8) at dispatch.c:3874
        i = 0
        pScreen = 0x1df61a0
        ret = <optimized out>
#11 0x000000000047aa9f in InitOutput (pScreenInfo=pScreenInfo@entry=0x82dd60 <screenInfo>, argc=argc@entry=1, argv=argv@entry=0x7fffc19f4eb8) at xf86Init.c:886
        pScrn = 0x1df5950
        i = 0
        j = <optimized out>
        k = <optimized out>
        scr_index = <optimized out>
        modulelist = <optimized out>
        optionlist = 0x1de2660
        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=0x7fffc19f4eb8, envp=<optimized out>) at main.c:200
        i = <optimized out>
        alwaysCheckForInput = {0, 1}
#13 0x00007fd2c6429e95 in __libc_start_main (main=0x426c60 <main>, argc=1, argv=0x7fffc19f4eb8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, 
    stack_end=0x7fffc19f4ea8) at libc-start.c:285
        result = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, -405889514456135042, 4353125, 140736441831088, 0, 0, 406026131390155390, 430218173046016638}, mask_was_saved = 0}}, priv = {
            pad = {0x0, 0x0, 0x5a3880 <__libc_csu_init>, 0x7fffc19f4eb8}, data = {prev = 0x0, cleanup = 0x0, canceltype = 5912704}}}
        not_first_call = <optimized out>
#14 0x0000000000426c8e in _start ()
No symbol table info available.
[Thread 0x7fd2c8efb9c0 (LWP 1345) exited]

Program terminated with signal SIGABRT, Aborted.
The program no longer exists.

Michel Dänzer Feb. 21, 2014, 2:25 a.m. UTC | #8

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?

Dave Airlie Feb. 21, 2014, 2:37 a.m. UTC | #9

On Fri, Feb 21, 2014 at 12:25 PM, Michel Dänzer <[e-mail]> 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.

Patch

--- 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