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] 1: [0xffffe420] 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] xorg.conf 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] Xorg.0.log
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) at ../../../miext/damage/damage.c:658 #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) at ../../render/render.c:1403 #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 ) at ../../dix/main.c:452
(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.
pushed, thanks.
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.