Created attachment 35090 [details] [review] Xorg logfile Hi, I'm trying to fire up my triple head setup with a Radeon 5750, but in the end Xorg segfaults. First of all the setup: Fedora Rawhide x86_64 xorg-x11-server-Xorg-1.8.0-6.fc14.x86_64 xorg-x11-drv-ati-6.13.0-1.20100406git819b40153.fc14.x86_64 (also tried current git) kernel-2.6.34-0.28.rc3.git3.fc14.x86_64 3x Samsung Syncmaster 2343bw with a strange 2048x1152 resolution Two of the screens are attached via dvi-d, the other one is attached via hdmi-to-dvi 02:00.0 VGA compatible controller: ATI Technologies Inc Device 68be (prog-if 00 [VGA controller]) Subsystem: Hightech Information System Ltd. Device 2287 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at d0000000 (64-bit, prefetchable) [size=256M] Memory at efcc0000 (64-bit, non-prefetchable) [size=128K] I/O ports at cc00 [size=256] Expansion ROM at efca0000 [disabled] [size=128K] Capabilities: [50] Power Management version 3 Capabilities: [58] Express Legacy Endpoint, MSI 00 Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?> Capabilities: [150] Advanced Error Reporting Kernel driver in use: radeon Kernel modules: radeon So far using only two of three screens aka dual head connected works fine. No problems so far. Just a lot of error messages during boot until Xorg fires up. HDMI/DVI mixed setup works out of the box. See log.dh for complete dmesg output. Error message repeated several times: radeon 0000:02:00.0: object_init failed for (9437184, 0x00000002) [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (9437184, 2, 4096, -22) [drm:radeon_gart_bind] *ERROR* trying to bind memory to unitialized GART ! [drm:radeon_ttm_backend_bind] *ERROR* failed to bind 2304 pages at 0x00000000 [TTM] Couldn't bind backend. When I boot Linux with three screens connected, the colors of one monitor are wrong. Black is dark green, white is light green which is difficult to read. Other colors are also some sort of green. But at least the console is shown and in sync with the other screens. So KMS is able to fire up all screens. Again there are lots of the above error messages. See log.th Xorg segfaults. GDB output and Xorg.log are attached, but I'm not sure if the xorg.log is consistent, beside the missing debugging symbols, to the gdb output. Program received signal SIGSEGV, Segmentation fault. 0x00007fa49766dd00 in drmmode_load_cursor_argb (crtc=0xc89b50, image=0xca79f0) at /usr/include/bits/string3.h:52 warning: Source file is more recent than executable. 52 return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest)); (gdb) bt full #0 0x00007fa49766dd00 in drmmode_load_cursor_argb (crtc=0xc89b50, image=0xca79f0) at /usr/include/bits/string3.h:52 drmmode_crtc = 0xc8a610 ptr = 0xc89b50 #1 0x0000000000534e05 in xf86_crtc_convert_cursor_to_argb (crtc=0xc89b50, src=0xd67170 "") at xf86Cursors.c:218 scrn = <value optimized out> xf86_config = 0xc87830 cursor_info = 0xca7780 cursor_image = 0xca79f0 x = <value optimized out> y = <value optimized out> xin = 63 yin = 63 stride = 16 flags = 25106 bits = <value optimized out> #2 0x0000000000535a10 in xf86_load_cursor_image (scrn=<value optimized out>, src=0xd67170 "") at xf86Cursors.c:452 crtc = 0xc89b50 xf86_config = 0xc87830 c = <value optimized out> #3 0x00000000005384f1 in xf86SetCursor (pScreen=0xc94350, pCurs=0xcbd120, x=<value optimized out>, y=<value optimized out>) at xf86HWCurs.c:148 ScreenPriv = <value optimized out> infoPtr = 0xca7780 bits = 0xd67170 "" #4 0x00000000005378c0 in xf86CursorSetCursor (pDev=0xcdb910, pScreen=0xc94350, pCurs=0xcbd120, x=3072, y=576) at xf86Cursor.c:350 ScreenPriv = 0xcaba00 infoPtr = 0xca7780 PointPriv = 0xca75b0 #5 0x0000000000456fe7 in miPointerUpdateSprite (pDev=0xcdb910) at mipointer.c:402 pScreen = 0xc94350 pScreenPriv = 0xca75b0 pCursor = <value optimized out> x = 3072 y = 576 devx = 4648 devy = 4712 pPointer = 0xd6fbf0 #6 0x0000000000457887 in miPointerDisplayCursor (pDev=0xcdb910, pScreen=0xc94350, pCursor=0xcbd120) at mipointer.c:197 pPointer = <value optimized out> #7 0x00000000004a2df3 in CursorDisplayCursor (pDev=0xcdb910, pScreen=0xc94350, pCursor=0xd43ba0) at cursor.c:155 cs = 0xcc24f0 ret = <value optimized out> ---Type <return> to continue, or q <return> to quit--- backupProc = 0x4a2c50 <CursorDisplayCursor> #8 0x0000000000562a91 in AnimCurDisplayCursor (pDev=0xcdb910, pScreen=0xc94350, pCursor=0xd43ba0) at animcur.c:247 as = 0xcc2d70 ret = <value optimized out> #9 0x0000000000437786 in UpdateSpriteForScreen (pDev=0xcdb910, pScreen=0xc94350) at events.c:3084 pSprite = 0xd661f0 win = <value optimized out> #10 0x00000000004573cb in miPointerWarpCursor (pDev=0xcdb910, pScreen=0xc94350, x=<value optimized out>, y=<value optimized out>) at mipointer.c:343 pPointer = <value optimized out> changedScreen = 1 '\001' pScreenPriv = 0xca75b0 #11 0x000000000051f681 in xf86WarpCursor (pDev=0xcdb910, pScreen=0xc94350, x=3072, y=576) at xf86Cursor.c:473 sigstate = 0 #12 0x000000000045713c in miPointerSetCursorPosition (pDev=0xcdb910, pScreen=0xc94350, x=3072, y=576, generateEvent=0) at mipointer.c:239 pScreenPriv = <value optimized out> #13 0x0000000000562390 in AnimCurSetCursorPosition (pDev=0xcdb910, pScreen=0xc94350, x=3072, y=576, generateEvent=<value optimized out>) at animcur.c:266 as = 0xcc2d70 ret = 0 #14 0x0000000000437979 in InitializeSprite (pDev=0xcdb910, pWin=<value optimized out>) at events.c:3016 pSprite = 0xd661f0 pScreen = 0xc94350 #15 0x00000000004268ae in EnableDevice (dev=0xcdb910, sendevent=1 '\001') at devices.c:299 prev = <value optimized out> ret = <value optimized out> other = <value optimized out> enabled = <value optimized out> flags = {0 <repeats 40 times>} #16 0x0000000000427045 in InitCoreDevices () at devices.c:613 No locals. #17 0x000000000042197a in main (argc=<value optimized out>, argv=0x7fff0f5daa08, envp=<value optimized out>) at main.c:257 i = <value optimized out> alwaysCheckForInput = {0, 1} (gdb) continue Continuing. Backtrace: 0: /usr/bin/X (xorg_backtrace+0x28) [0x49e6f8] 1: /usr/bin/X (0x400000+0x603c9) [0x4603c9] 2: /lib64/libc.so.6 (0x357cc00000+0x339d0) [0x357cc339d0] 3: /usr/lib64/xorg/modules/drivers/radeon_drv.so (0x7fa497595000+0xd8d00) [0x7fa49766dd00] 4: /usr/bin/X (0x400000+0x134e05) [0x534e05] 5: /usr/bin/X (0x400000+0x135a10) [0x535a10] 6: /usr/bin/X (0x400000+0x1384f1) [0x5384f1] 7: /usr/bin/X (0x400000+0x1378c0) [0x5378c0] 8: /usr/bin/X (miPointerUpdateSprite+0x157) [0x456fe7] 9: /usr/bin/X (0x400000+0x57887) [0x457887] 10: /usr/bin/X (0x400000+0xa2df3) [0x4a2df3] 11: /usr/bin/X (0x400000+0x162a91) [0x562a91] 12: /usr/bin/X (0x400000+0x37786) [0x437786] 13: /usr/bin/X (miPointerWarpCursor+0x15b) [0x4573cb] 14: /usr/bin/X (0x400000+0x11f681) [0x51f681] 15: /usr/bin/X (0x400000+0x5713c) [0x45713c] 16: /usr/bin/X (0x400000+0x162390) [0x562390] 17: /usr/bin/X (0x400000+0x37979) [0x437979] 18: /usr/bin/X (EnableDevice+0x21e) [0x4268ae] 19: /usr/bin/X (0x400000+0x27045) [0x427045] 20: /usr/bin/X (0x400000+0x2197a) [0x42197a] 21: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x357cc1ed2d] 22: /usr/bin/X (0x400000+0x21579) [0x421579] Segmentation fault at address (nil) Fatal server error: Caught signal 11 (Segmentation fault). Server aborting When I attach the third screen to a running xorg dual head session it is recognized by xrandr. But when I activate the third screen via xrandr then xorg segfaults again. After this there's no greenish color anymore on the console. Program received signal SIGSEGV, Segmentation fault. 0x00007f17784edd00 in drmmode_load_cursor_argb (crtc=0x1a5c840, image=0x1a796b0) at /usr/include/bits/string3.h:52 If you need further information, do not hesitate to ask. Regards Marcel
Created attachment 35091 [details] Output of dmesg - two screens attached
Created attachment 35092 [details] Output of dmesg - three screens attached
(In reply to comment #0) > 3x Samsung Syncmaster 2343bw with a strange 2048x1152 resolution > Two of the screens are attached via dvi-d, the other one is attached via > hdmi-to-dvi For triple head, one of the monitors has to be displayport. You can only use two non-displayport monitors independently. That said, the driver should deal with this case more gracefully.
Can you install the xserver and xf86-video-ati debugging symbols and get a better back trace?
fixed in 4656f5dff1ed72fa2c7a1484305f2aef7b65ff2b
Hi Alex, Xorg doesn't segfault anymore. The fix looks very simple. Has anybody used more than two screens with evergreen before? Now the card drives all screens (2xDVI + HDMI), but one has the same wrong colors as I've seen without Xorg, which makes sense because of KMS. You pointed out that I'll need a DP screen. Is it really necessary? Because the mouse pointer is correctly drawn on every screen. Dmesg points out that the DP and HDMI port share the same UNIPHY. Afaik it is possible to connect HDMI to DP and DP will create a HDMI signal. Probably the HDMI port of this card is already connected to the DP and I don't need a DP screen. If not, pls proof me wrong. The broken screen is connected via DVI and it's the third connected screen. Now either the third screen should be deactivated because it is not possible to drive it correctly or there's another bug if you connect more than two screens. This leads back to my first question.
(In reply to comment #6) > Hi Alex, > > Xorg doesn't segfault anymore. The fix looks very simple. Has anybody used more > than two screens with evergreen before? > > Now the card drives all screens (2xDVI + HDMI), but one has the same wrong > colors as I've seen without Xorg, which makes sense because of KMS. You pointed > out that I'll need a DP screen. Is it really necessary? Because the mouse > pointer is correctly drawn on every screen. Dmesg points out that the DP and > HDMI port share the same UNIPHY. Afaik it is possible to connect HDMI to DP and > DP will create a HDMI signal. Probably the HDMI port of this card is already > connected to the DP and I don't need a DP screen. If not, pls proof me wrong. > The broken screen is connected via DVI and it's the third connected screen. > > Now either the third screen should be deactivated because it is not possible to > drive it correctly or there's another bug if you connect more than two screens. > This leads back to my first question. It either has to be DP or use an *active* DP convertor. i.e. not a DP->DVI or DP->HDMI. The thing is there are only 3 clocks, and one clock drives only DP frequencies from what I know. I'm not sure if the 3rd clock can be persuaded to run at non DP rates. Dave.
The clocking gets a bit complex, but there are basically only 2 programmable pixel PLLs for the CRTC clocks and digital PHY blocks. In most cases, the CRTC clock and PHY are derived from one of the two pixel PLLs. For the >2 head case, the CRTC clocks on the additional heads are derived from the an additional DCPLL and the additional PHYs are driven by an external PLL. This works for DP because DP uses a fixed clock unlike non-DP. If the timing is the same on several non-DP monitors in theory they could be driven by the same pixel PLL, but that will not work for the general case (I'm not sure this has been verified on the hw or will work reliably). You can also drive the PHYs with the same CRTC in which case all heads driven by that CRTC will get the exact some timing. If several heads share the same PHY block and links, they can not be used at the same time independantly. But basically, all heads >2 have to be DP from the GPU's perspective. As Dave said this can be native DP or an active DP to DVI convertor since the active convertor looks like DP to the GPU.
Created attachment 35160 [details] Photo of third head with mouse cursor Thanks for all these nice information. It sounds reasonable. But I'm still confused that the mouse cursor is working as it should. Even animations (fedoras blue bubbles). The photo shows the kde mouse settings dialog. The cursor hovers over a snapshot of the same cursor. I'm not an expert in signal theory, but first of all, I would expect that the mouse cursor is also distorted. Second, if there's no correct clock then there shouldn't be any reasonable shape or color. Is it difficult to drive all PLLs with the same clock? I looked around and getting one of those active converters will take time.
this patch: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=677d07683ea826c19ddcb156e9c1337cd7bd8539 should fix the colormap issues. If you run the exact same mode on two of the heads they should in theory work if they use the same PLL since they use the same clock. So it may work for your specific case, but not in a general way. If you changes the modes on one of the heads, it would break the other head that shares that PLL.
Awesome. Colormapping is correct now. So far everything is working fine. Thx. What about these error message repeated several times? They appear when one or more heads are attached. radeon 0000:02:00.0: object_init failed for (9437184, 0x00000002) [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (9437184, 2, 4096, -22) [drm:radeon_gart_bind] *ERROR* trying to bind memory to unitialized GART ! [drm:radeon_ttm_backend_bind] *ERROR* failed to bind 2304 pages at 0x00000000 [TTM] Couldn't bind backend.
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.