I'm currently testing drm-next from airlied tree (git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git, at revision cecc6b63), libdrm from git (master), radeon driver from git (master - 10a58d54), xserver 1.6.3. The card is a M56. X crashes fairly often, I found that I can reproduce easily under KDE4 using krunner (alt+f2) and starting typing (X dies immediately). A sample backtrace: Backtrace: 0: /usr/bin/X11/X(xorg_backtrace+0x26) [0x4edff6] 1: /usr/bin/X11/X(xf86SigHandler+0x39) [0x4834f9] 2: /lib/libc.so.6 [0x7fc0567ccdb0] 3: /usr/lib/xorg/modules/drivers//radeon_drv.so [0x7fc054fe72fd] 4: /usr/lib/xorg/modules//libexa.so(exaCompositeRects+0x568) [0x7fc0548bacc8] 5: /usr/lib/xorg/modules//libexa.so(exaGlyphs+0x52d) [0x7fc0548b693d] 6: /usr/bin/X11/X [0x5343f1] 7: /usr/bin/X11/X [0x52e535] 8: /usr/bin/X11/X(Dispatch+0x364) [0x44d344] 9: /usr/bin/X11/X(main+0x3aa) [0x43329a] 10: /lib/libc.so.6(__libc_start_main+0xe6) [0x7fc0567b95c6] 11: /usr/bin/X11/X [0x432739] (Side note: radeon_drv is compiled with "-O0 -g", still the backtrace is rather uninformative) I've done a post mortem analysis with gdb (I've taken the base address of the relocated radeon_drv.so from the running server, crashed X and subtracted the base address from the address in the stack trace); the faulting address is 0x1042fd: 0x1042fd is in R600Composite (r600_exa.c:1857). 1855 vb = (pointer)((char*)accel_state->vb_ptr+accel_state->vb_index*16); 0x00000000001042cc <R600Composite+1123>: mov -0x10(%rbp),%rax 0x00000000001042d0 <R600Composite+1127>: mov 0xc8(%rax),%rax 0x00000000001042d7 <R600Composite+1134>: mov %rax,%rdx 0x00000000001042da <R600Composite+1137>: mov -0x10(%rbp),%rax 0x00000000001042de <R600Composite+1141>: mov 0xb0(%rax),%eax 0x00000000001042e4 <R600Composite+1147>: shl $0x4,%eax 0x00000000001042e7 <R600Composite+1150>: cltq 0x00000000001042e9 <R600Composite+1152>: lea (%rdx,%rax,1),%rax 0x00000000001042ed <R600Composite+1156>: mov %rax,-0x8(%rbp) 1856 1857 vb[0] = (float)dstX; 0x00000000001042f1 <R600Composite+1160>: cvtsi2ssl -0xbc(%rbp),%xmm0 0x00000000001042f9 <R600Composite+1168>: mov -0x8(%rbp),%rax 0x00000000001042fd <R600Composite+1172>: movss %xmm0,(%rax) I'm attaching kernel and server logs.
Created attachment 29346 [details] X log
Created attachment 29347 [details] kernel log
EXA is known to cause crashes on R6xx/R7xx. AStorm collected yesterday nice backtrace from his EXA crash: http://dpaste.com/91252/
(In reply to comment #3) > EXA is known to cause crashes on R6xx/R7xx. Note that I'm referring only to KMS from drm-next; the same setup without KMS is rock solid.
(In reply to comment #4) > (In reply to comment #3) > > EXA is known to cause crashes on R6xx/R7xx. > > Note that I'm referring only to KMS from drm-next; the same setup without KMS > is rock solid. Yes, I've meant that :) EXA works for me stable on not-KMS, the same for AStorm. Just in connection with KMS it crashes.
Please try again with updated xf86-video-ati to today's master.
(In reply to comment #6) > Please try again with updated xf86-video-ati to today's master. It seems that 0bb0ff0e fixed EXA related crashes.
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.