Bug 20410

Summary: Crash on X1250 when use of XV involves scaling
Product: xorg Reporter: Paul Gardiner <ati>
Component: Driver/RadeonAssignee: xf86-video-ati maintainers <xorg-driver-ati>
Status: RESOLVED INVALID QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium    
Version: 7.4 (2008.09)   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Xorg log at time of crash
none
xorg.conf at time of crash none

Description Paul Gardiner 2009-03-01 09:21:43 UTC 
I'm running a MythTV frontend that has a K9AGM2 motherboard, which includes an X1250 IGP. I use the radeon driver to generate an interleaved 720x576 mode from VGA which is routed through the well known VGA to Scart circuit to my TV. I select xv-blit as the render method.

All works well in situations where no scaling is necessary, but if there is scaling then - although playback is successful - the X server crashes during menu changes after playback. (It reliably fails on repeating the process). If I select xlib for rendering then the crash doesn't occur. I see:


Backtrace:
0: /usr/bin/X(xf86SigHandler+0x9e) [0x80a22ae]
1: [0xb7f61400]
2: /usr/lib/xorg/modules/extensions//libdri.so [0xb7c7badf]
3: /usr/lib/xorg/modules/extensions//libdri.so(DRIClipNotify+0x1ec) [0xb7c7bdd7]
4: /usr/bin/X [0x80ad6a8]
5: /usr/bin/X(miValidateTree+0x5b3) [0x80fd27a]
6: /usr/lib/xorg/modules/extensions//libdri.so(DRIValidateTree+0x48) [0xb7c7aae8]
7: /usr/bin/X(UnmapWindow+0x126) [0x806f750]
8: /usr/bin/X(ProcUnmapWindow+0x49) [0x807effe]
9: /usr/bin/X(Dispatch+0x2b4) [0x807f753]
10: /usr/bin/X(main+0x58a) [0x806c49b]
11: /lib/libc.so.6(__libc_start_main+0xe6) [0xb7d715b6]
12: /usr/bin/X [0x806b7c1]

Fatal server error:
Caught signal 11.  Server aborting

(II) event2: Close
(II) RADEON(0): RADEONLeaveVT
(II) RADEON(0): EngineRestore (32/32)
(II) RADEON(0): RADEONRestore
(II) RADEON(0): ParseTable said: CD_SUCCESS
Output CRT1 disable success
(II) RADEON(0): ParseTable said: CD_SUCCESS
Blank CRTC 0 success
(II) RADEON(0): ParseTable said: CD_SUCCESS
Disable CRTC 0 success
(II) RADEON(0): ParseTable said: CD_SUCCESS
Blank CRTC 1 success
(II) RADEON(0): ParseTable said: CD_SUCCESS
Disable CRTC 1 success
(II) RADEON(0): RADEONRestoreMemMapRegisters() : 
(II) RADEON(0):   MC_FB_LOCATION   : 0x3fff3800 0x3fff3800
(II) RADEON(0):   MC_AGP_LOCATION  : 0x003f0000
(II) RADEON(0): avivo_restore !
(II) RADEON(0): ParseTable said: CD_SUCCESS
Enable CRTC 0 success
(II) RADEON(0): ParseTable said: CD_SUCCESS
Unblank CRTC 0 success
(II) RADEON(0): Ok, leaving now...


at the end of Xorg.0.0.log, and:


Mar  1 11:13:46 slinky local0.info mythfrontend: 2009-03-01 11:13:46.075 TV: Changing from WatchingPreRecorded to None
Mar  1 11:13:47 slinky user.info kernel: [drm] Num pipes: 1
Mar  1 11:13:47 slinky local0.info mythfrontend: mythfrontend: Fatal IO error: client killed

in my logs.
Comment 1 Alex Deucher 2009-03-01 10:24:22 UTC 
Please attach your full xorg log and config.
Comment 2 Paul Gardiner 2009-03-01 12:48:41 UTC 
Created attachment 23417 [details]
Xorg log at time of crash
Comment 3 Paul Gardiner 2009-03-01 12:51:14 UTC 
Created attachment 23418 [details]
xorg.conf at time of crash
Comment 4 Michel Dänzer 2009-03-01 23:40:34 UTC 
A gdb backtrace of the crash would also be useful.
Comment 5 Paul Gardiner 2009-03-02 01:06:07 UTC 
I'm using the minimyth, where I have no build capability, so I'm not sure whether there's a way I can get a gdb backtrace, but I'll look into it.  Presumably I'd need to build a debug version of xorg?
Comment 6 Michel Dänzer 2009-03-02 01:16:31 UTC 
(In reply to comment #5)
> Presumably I'd need to build a debug version of xorg?

That would be ideal, but the gdb backtrace might be more useful even without debugging symbols.
Comment 7 Paul Gardiner 2009-03-02 01:33:18 UTC 
So is that backtrace I gave in the frist comment not useful because it's from a different thread? Or is it a different form of backtrace?

What would it be that I'd need to run under gdb, mythfrontend presumably?

Sorry to be thick. I don't know the X architecture at all.
Comment 8 Michel Dänzer 2009-03-02 02:02:42 UTC 
(In reply to comment #7)
> So is that backtrace I gave in the frist comment not useful because it's from a
> different thread? Or is it a different form of backtrace?

The latter; the backtraces from glibc just aren't as reliable as those from gdb. E.g. the stack frames 1 and 2 are missing information.

> What would it be that I'd need to run under gdb, mythfrontend presumably?

No, the process which crashes, i.e. the X server process.
Comment 9 Paul Gardiner 2009-03-02 05:24:02 UTC 
Sorry minimyth doesn't seem to have gdb. I'll talk to the creator of minimyth to see if there's a way around it.

I also have a harddisc with a SuSE distro which used to run with the same hardware. If I can get that to crash in the same way, then that might provide a way forward.
Comment 10 Paul Gardiner 2009-03-08 06:38:36 UTC 
On the same hardware, I tried several versions of the radeon driver under SuSE 11.1 and wasn't able to reproduce the problem.

I've also set up things here so I can build minimyth myself (the intention to build the debug version), but with the version I've built the problem has gone away (that's using 6.11.0 of the radeon driver.

If I don't see the problem reappear over the next week, I'll mark this bug invalid.

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.