Bug 13407 - Radeon Mobility crashes with EXA + RenderAccel
Summary: Radeon Mobility crashes with EXA + RenderAccel
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/Acceleration/EXA (show other bugs)
Version: 7.3 (2007.09)
Hardware: x86 (IA32) All
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
Keywords: patch
Depends on:
Blocks: xorg-server-1.4.1
  Show dependency treegraph
Reported: 2007-11-27 09:53 UTC by Timo Jyrinki
Modified: 2008-05-16 09:54 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

xorg.conf (4.47 KB, text/plain)
2007-11-27 09:55 UTC, Timo Jyrinki
no flags Details
Xorg.0.log (44.86 KB, text/plain)
2007-11-27 09:56 UTC, Timo Jyrinki
no flags Details
Possible fix, backport from master branch (781 bytes, patch)
2007-12-03 07:26 UTC, Michel Dänzer
no flags Details | Splinter Review

Description Timo Jyrinki 2007-11-27 09:53:41 UTC
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.
Comment 1 Timo Jyrinki 2007-11-27 09:55:56 UTC
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.
Comment 2 Timo Jyrinki 2007-11-27 09:56:37 UTC
Created attachment 12744 [details]
Comment 3 Michel Dänzer 2007-11-27 10:07:53 UTC
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?
Comment 4 Timo Jyrinki 2007-11-27 10:37:06 UTC
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
Comment 5 Michel Dänzer 2007-11-28 00:57:54 UTC
(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.
Comment 6 Timo Jyrinki 2007-12-03 07:08:38 UTC
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>
Comment 7 Michel Dänzer 2007-12-03 07:26:00 UTC
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?
Comment 8 Timo Jyrinki 2007-12-03 08:52:12 UTC
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.
Comment 9 Michel Dänzer 2007-12-03 09:07:08 UTC
Okay, marking as a blocker for 1.4.1.
Comment 10 Timo Jyrinki 2007-12-11 03:03:36 UTC
Adding the patch keyword.
Comment 11 Daniel Stone 2008-05-16 09:54:18 UTC
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.