Using x.org-server 1.4.1~git20071119-1ubuntu1, ati driver 6.7.196-1. Ie. the ones currently in ubuntu development version.
I get the following backtrace when using EXA and RenderAccel, but not if I use EXA otherwise without RenderAccel (setting it to False):
0: /usr/bin/X(xf86SigHandler+0x7e) [0x80c744e]
2: /usr/lib/xorg/modules/drivers//radeon_drv.so [0xb7b1e929]
3: /usr/lib/xorg/modules//libexa.so(exaGlyphs+0x7a9) [0xb794c349]
4: /usr/bin/X [0x8172604]
5: /usr/bin/X(CompositeGlyphs+0x9a) [0x8159b5a]
6: /usr/bin/X [0x81614e9]
7: /usr/bin/X [0x815c875]
8: /usr/bin/X [0x814feee]
9: /usr/bin/X(Dispatch+0x2cf) [0x808d93f]
10: /usr/bin/X(main+0x48b) [0x80747ab]
11: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe0) [0xb7d29050]
12: /usr/bin/X(FontFileCompleteXLFD+0x20d) [0x8073b21]
Is there something obvious I'm still missing that could cause this? Using 2.6.22 kernel and libdrm 2.3.0.
Created attachment 12743 [details]
Same problem occurs (ie. a crash shortly after desktop startup, eg. starting a terminal and typing something) if I remove AccelDFS, GARTSize and EnablePageFlip lines. The problem disappears if I uncomment the RenderAccel false line.
Created attachment 12744 [details]
Does this also happen with Option "EXANoComposite" instead of "RenderAccel" "false"? (What's the problem with the default of Option "RenderAccel"?)
Can you get a more useful backtrace from gdb?
EXANoComposite fixes the problem. I also found this undocumented (?) MigrationHeuristic and noticed that Option "MigrationHeuristic" "greedy" seems to fix the problem, too. But without them, here's the trace with gdb:
#0 0xb7a6f594 in RADEONHostDataBlit (pScrn=0x821d2f0, cpp=4, w=0,
dstPitchOff=8021772, bufPitch=0xbf8fb764, x=0, y=0xbf8fb788, h=0xbf8fb790,
hpass=0xbf8fb768) at ../../src/radeon_accel.c:699
#1 0xb7aa7929 in RADEONUploadToScreenCP (pDst=0x84a2928, x=0, y=0, w=0, h=2,
src=0x8471bd0 "", src_pitch=0) at ../../src/radeon_exa_funcs.c:272
#2 0xb78d5349 in exaGlyphs (op=3 '\003', pSrc=0x84a2dc8, pDst=0x850c228,
maskFormat=0x0, xSrc=0, ySrc=0, nlist=0, list=0xbf8fbde4,
glyphs=0xbf8fb9f4) at ../../exa/exa_render.c:1199
#3 0x08172604 in damageGlyphs (op=216 '�', pSrc=0x84a2dc8, pDst=0x850c228,
maskFormat=0x825ecc0, xSrc=<value optimized out>,
ySrc=<value optimized out>, nlist=1, list=0xbf8fbde4, glyphs=0xbf8fb9e4)
#4 0x08159b5a in CompositeGlyphs (op=<value optimized out>, pSrc=0x84a2dc8,
pDst=0x850c228, maskFormat=0x825ecc0, xSrc=0, ySrc=0, nlist=1,
lists=0xbf8fbde4, glyphs=0xbf8fb9e4) at ../../render/picture.c:1785
#5 0x081614e9 in ProcRenderCompositeGlyphs (client=0x84aba20)
#6 0x0815c875 in ProcRenderDispatch (client=0x0) at ../../render/render.c:2002
#7 0x0814feee in XaceCatchExtProc (client=0x84aba20) at ../../Xext/xace.c:299
#8 0x0808d93f in Dispatch () at ../../dix/dispatch.c:502
#9 0x080747ab in main (argc=10, argv=0xbf8fc684, envp=Cannot access memory at address 0x8
(In reply to comment #4)
> EXANoComposite fixes the problem.
I don't understand how that can cause exaGlyphs to behave differently from "RenderAccel" "off" though. When this happens, is pExaScr->info->PrepareComposite == NULL in the exaGlyphs frame?
> I also found this undocumented (?) MigrationHeuristic
It's documented in the exa(4) manpage.
> and noticed that Option "MigrationHeuristic" "greedy" seems
> to fix the problem, too.
It probably just happens to avoid it because it tends to keep pixmaps out of offscreen memory, preventing acceleration.
Sorry for the delay. After two "up":s:
#2 0xb78a7349 in exaGlyphs (op=3 '\003', pSrc=0x8b03010, pDst=0x8b03178,
maskFormat=0x0, xSrc=0, ySrc=0, nlist=0, list=0xbfa56f44,
glyphs=0xbfa56b54) at ../../exa/exa_render.c:1199
(gdb) print pExaScr->info->PrepareComposite
$1 = (Bool (*)(int, PicturePtr, PicturePtr, PicturePtr, PixmapPtr, PixmapPtr,
PixmapPtr)) 0xb7a76640 <R200PrepareCompositeCP>
Created attachment 12913 [details] [review]
Possible fix, backport from master branch
Ah, I was confused by RenderAccel being disabled in the attached xorg.conf, so I didn't understand the problem correctly...
Does this patch fix it?
Yes! Confirming that applying that patch fixes the problem for me, I cannot get it to crash anymore. To be fool-proof, I also removed the patch, rebuilt again and switched back and forth between the builds to see that it's really fixing it.
Okay, marking as a blocker for 1.4.1.
Adding the patch keyword.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.