Bug#533444: xserver-xorg-video-ati: X server hang while starting opengl application
On Sat, 13 Mar 2010 16:05:11 +0100 Brice Goglin wrote: Henri, does this problem still occur with latest packages? I don't have the hw anymore to try this out. The bug can be closed as far I'm concerned. I'll try to reproduce this with latest packages, If I get access to such hardware later. -Henri -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201004021926.04919...@jakorasia.info
Bug#533444: xserver-xorg-video-ati: X server hang while starting opengl application
I have a similar problem and backtrace using Kubuntu Jaunty with the radeon- driver. See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/348332 Maybe this is related? -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533444: xserver-xorg-video-ati: X server hang while starting opengl application
On Sat, 2009-06-27 at 22:21 +0300, Henri Valta wrote: On Friday 26 June 2009 11:18:33 Michel Dänzer wrote: You could try current upstream mesa Git master, there have been a lot of fixes in the Radeon drivers for GPU lockups and other stability issues since the 7.5 branch. If it still happens with that, please report it upstream at http://bugs.freedesktop.org , product Mesa, component Drivers/DRI/r300, with specific information about the apps triggering it. With upstream mesa git master, the Xserver no longer freezes or causes oops, but exits with -1 status, giving the following output to stdout/stderr. Nothing interesting in Xorg logs Dac detection success Unhandled monitor type 0 Dac detection success Unhandled monitor type 0 Dac detection success Unhandled monitor type 0 Dac detection success Unhandled monitor type 0 Dac detection success Unhandled monitor type 0 Dac detection success Unhandled monitor type 0 Dac detection success Unhandled monitor type 0 Dac detection success Unhandled monitor type 0 r300VertexProgUpdateParams:Params exhausted xinit: connection to X server lost. I'll look more into debugging this, maybe try some git bisect and report upstream, if this is not already known issue. Please do. This sounds like a separate issue in mesa Git, which may just be masking your original problem. FWIW, it looks like disabling 'desktop effects' should work around this problem, unless your application is using indirect rendering for some reason. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533444: xserver-xorg-video-ati: X server hang while starting opengl application
On Friday 26 June 2009 11:18:33 Michel Dänzer wrote: You could try current upstream mesa Git master, there have been a lot of fixes in the Radeon drivers for GPU lockups and other stability issues since the 7.5 branch. If it still happens with that, please report it upstream at http://bugs.freedesktop.org , product Mesa, component Drivers/DRI/r300, with specific information about the apps triggering it. With upstream mesa git master, the Xserver no longer freezes or causes oops, but exits with -1 status, giving the following output to stdout/stderr. Nothing interesting in Xorg logs Dac detection success Unhandled monitor type 0 Dac detection success Unhandled monitor type 0 Dac detection success Unhandled monitor type 0 Dac detection success Unhandled monitor type 0 Dac detection success Unhandled monitor type 0 Dac detection success Unhandled monitor type 0 Dac detection success Unhandled monitor type 0 Dac detection success Unhandled monitor type 0 r300VertexProgUpdateParams:Params exhausted xinit: connection to X server lost. I'll look more into debugging this, maybe try some git bisect and report upstream, if this is not already known issue. -Henri -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533444: xserver-xorg-video-ati: X server hang while starting opengl application
On Thu, 2009-06-25 at 18:50 +0300, Henri Valta wrote: With mesa packages build from todays debian-experimental mesa git branch, (7.5~rc3) the bt and oops is still the same. Any more ideas what to try? You could try current upstream mesa Git master, there have been a lot of fixes in the Radeon drivers for GPU lockups and other stability issues since the 7.5 branch. If it still happens with that, please report it upstream at http://bugs.freedesktop.org , product Mesa, component Drivers/DRI/r300, with specific information about the apps triggering it. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533444: xserver-xorg-video-ati: X server hang while starting opengl application
With mesa packages build from todays debian-experimental mesa git branch, (7.5~rc3) the bt and oops is still the same. Any more ideas what to try? -Henri -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533444: xserver-xorg-video-ati: X server hang while starting opengl application
On Thursday 18 June 2009 20:11:35 Henri Valta wrote: Ok, I compiled mesa 7.5~rc2-1 packages from debian-experimental git repository. The oops is still the same, gdb backtrace follows. I'll look into compiling a newer ddx driver next... With xserver-xorg-video-ati/radeon packages build from fdo git master branch, the oops and backtrace is identical. Now I'm trying to build the latest mesa packages using fdo git, but the old debian directory copied from debian git seems to need some adjusting as I'm getting issues on the install phase (trying to install some files to actual locations, not the fakeroot ones) -Henri -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533444: xserver-xorg-video-ati: X server hang while starting opengl application
On Thursday 18 June 2009 03:15:46 Alex Deucher wrote:
This is a pretty standard GPU hang. I'd suggest trying a newer ddx
and mesa 3d driver.
Ok, I compiled mesa 7.5~rc2-1 packages from debian-experimental git
repository. The oops is still the same, gdb backtrace follows.
I'll look into compiling a newer ddx driver next...
The gl graphics output I get on the screen is completely garbled (mostly color
gradients and some text strings going vertically, instead of horizontally)
However, after reboot, when switching on the KDE4 desktop effects/composited
desktop, I see briefly the old graphics buffer contents on the screen and the
game graphics look perfect on that flashback.
The desktop effects have been turned off during all the tests I've done to make
sure they are not causing any of the issues.
-Henri
Program received signal SIGINT, Interrupt.
0x7fab597da087 in ioctl () from /lib/libc.so.6
#0 0x7fab597da087 in ioctl () from /lib/libc.so.6
No symbol table info available.
#1 0x7fab58293623 in drmIoctl (fd=11, request=3223348302,
arg=0x7fffdbee5660) at ../../libdrm/xf86drm.c:187
ret = -1
#2 0x7fab5829386c in drmCommandWriteRead (fd=11, drmCommandIndex=value
optimized out, data=0x7fffdbee5660, size=18446744073709551615) at
../../libdrm/xf86drm.c:2400
No locals.
#3 0x7fab44a51b87 in r300UploadTexImages (rmesa=0x3eaa720, t=0x685e070,
face=2) at r300_texmem.c:459
i = 0
numLevels = 1
__func__ = r300UploadTexImages
#4 0x7fab44a551b2 in r300UpdateTextureState (ctx=0x32c9200) at
r300_texstate.c:520
i = 3
#5 0x7fab44a4de64 in r300UpdateShaderStates (rmesa=0x3eaa720) at
r300_state.c:2539
ctx = 0x32c9200
w_fmt = value optimized out
fgdepthsrc = value optimized out
#6 0x7fab44a50df0 in r300RunRender (ctx=0x32c9200, stage=value optimized
out) at r300_render.c:314
rmesa = 0x3eaa720
i = value optimized out
__func__ = r300RunRender
#7 0x7fab44aeff9f in _tnl_run_pipeline (ctx=0x32c9200) at
tnl/t_pipeline.c:158
tnl = 0x3e71b70
i = 0
#8 0x7fab44af05a4 in _tnl_draw_prims (ctx=0x32c9200, arrays=value
optimized out, prim=0x25842fc, nr_prims=1, ib=0x0, min_index=value optimized
out, max_index=value optimized out)
at tnl/t_draw.c:431
bo = {0x0 repeats 17 times, 0xffe0, 0x0, 0x7fab59a69f6f,
0x7d8700, 0x1, 0x7d7a00, 0x4f4861, 0xb2, 0x7fab44ae3d58, 0x0, 0x1040,
0x1040, 0x7fab44a4db56, 0x32c9200, 0x0,
0x685f9e0}
nr_bo = 0
tnl = 0x3e71b70
#9 0x7fab44ae8ead in vbo_exec_vtx_flush (exec=0x25840c0, unmap=0 '\0') at
vbo/vbo_exec_draw.c:350
ctx = 0x32c9200
#10 0x7fab44ae4312 in vbo_exec_wrap_buffers (exec=0x25840c0) at
vbo/vbo_exec_api.c:83
last_count = 6
__PRETTY_FUNCTION__ = vbo_exec_wrap_buffers
#11 0x7fab44ae4688 in vbo_exec_fixup_vertex (ctx=value optimized out,
attr=19, sz=4) at vbo/vbo_exec_api.c:224
exec = 0x25840c0
i = value optimized out
id = {0, 0, 0, 1}
#12 0x7fab44ae62df in vbo_VertexAttrib4fARB (index=value optimized out,
x=value optimized out, y=value optimized out, z=value optimized out,
w=value optimized out)
at vbo/vbo_attrib_tmp.h:342
ctx = 0xfff5
__FUNCTION__ = vbo_VertexAttrib4fARB
#13 0x7fab57e563d6 in __glXDisp_Render (cl=value optimized out,
pc=0x3933808 \f) at ../../glx/glxcmds.c:1801
entry = {bytes = 12, varsize = 0}
extra = value optimized out
proc = 0x7fab57e35180 __glXDisp_VertexAttrib4NubvARB
err = 0
client = 0x21fbe70
left = 0
cmdlen = 12
error = 0
commandsDone = 0
glxc = 0x327a890
sw = value optimized out
#14 0x7fab57e5a5e2 in __glXDispatch (client=0x21fbe70) at
../../glx/glxext.c:541
stuff = 0x3933800
opcode = value optimized out
cl = 0x336e7c0
retval = 1
#15 0x0044d374 in Dispatch () at ../../dix/dispatch.c:437
result = value optimized out
client = 0x21fbe70
nready = 0
start_tick = 10740
#16 0x0043321d in main (argc=8, argv=0x7fffdbee5eb8, envp=value
optimized out) at ../../dix/main.c:397
i = 1
alwaysCheckForInput = {0, 1}
--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533444: xserver-xorg-video-ati: X server hang while starting opengl application
Same problem (hang+kernel oops) with libdrm2 downgraded to 2.4.11-1
Previous report had libdrm2 2.4.11+git+20090519+f355ad8-1
Changing AccelMethod to exa produces following gdb backtrace (now using
downgraded libdrm2)
Program received signal SIGINT, Interrupt.
0x7fbfa7d1e087 in ioctl () from /lib/libc.so.6
#0 0x7fbfa7d1e087 in ioctl () from /lib/libc.so.6
No symbol table info available.
#1 0x7fbfa67d7623 in drmIoctl (fd=10, request=25668, arg=0x0) at
../../libdrm/xf86drm.c:187
ret = 15
#2 0x7fbfa67d7926 in drmCommandNone (fd=10, drmCommandIndex=value
optimized out) at ../../libdrm/xf86drm.c:2313
No locals.
#3 0x7fbfa5d09cf4 in RADEONDownloadFromScreenCP (pSrc=value optimized
out, x=0, y=15, w=21, h=0, dst=0x1da44c0 P, dst_pitch=84) at
../../src/radeon_exa_funcs.c:411
oldhpass = value optimized out
i = 117
hpass = 0
scratch_pitch_offset = 12061448
indirect = {idx = 0, start = 0, end = 0, discard = 0}
__head = value optimized out
pScrn = 0x12a0820
src =
0x7fbf9358
\b\b\bFF\b\b\bFF\b\b\bFF\b\b\bFFhhhFF\215\220\220FF\215\220\220FF\215\220\220FFA0A0A0FFB2B5B5FFC5CACAFFC5CACAFFC8D4D8FFC8D4D8FFD0D9DDFFC8D4D8FFD0D4D8FFD0D4D8FFD0D4D8FFD0D4D8FFC5CCCDFFC5CCCDFFB2B8BAFFA0A4A8FF\210\216\215FF\210\216\215FF`d`FF`d`FFHIJFFHIJFF
bpp = value optimized out
datatype = 6
src_pitch_offset = 11940080
scratch_pitch = 128
scratch_off = 0
scratch = 0x12e7a70
#4 0x7fbfa544a2e9 in exaCopyDirty (migrate=0x7fff101aab60,
pValidDst=0x1da3f40, pValidSrc=value optimized out, transfer=0x7fbfa5d09750
RADEONDownloadFromScreenCP, fallback_src=
0x7fbf9e07c000
\002\002\002\002\006\006\006\027\a\a\a\031\a\a\a\031\a\a\a\031\a\a\a\031\a\a\a\031\006\006\006\027\002\002\002\b\b\b\bl,
fallback_dst=0x1da44c0 P, fallback_srcpitch=128,
fallback_dstpitch=84, fallback_index=1, sync=0x7fbfa590 exaWaitSync)
at ../../exa/exa_migration.c:210
pPixmap = 0x1da4480
pExaPixmap = 0x1da3f00
damage = value optimized out
CopyReg = {extents = {x1 = 0, y1 = 0, x2 = 21, y2 = 15}, data = 0x0}
save_offscreen = 1
save_pitch = 128
pBox = 0x7fff101aa9a0
nbox = 0
access_prepared = 0
need_sync = 0
#5 0x7fbfa544a620 in exaDoMoveOutPixmap (migrate=0x7fff101aab60) at
../../exa/exa_migration.c:258
pPixmap = 0x1da4480
#6 0x7fbfa544ad47 in exaDoMigration (pixmaps=0x7fff101aab60, npixmaps=1,
can_accel=0) at ../../exa/exa_migration.c:679
pExaScr = 0x12e74c0
i = 1
j = value optimized out
__func__ = exaDoMigration
#7 0x7fbfa5446c8a in exaGetImage (pDrawable=0x1da4480, x=0, y=0, w=21,
h=15, format=2, planeMask=4294967295, d=0x7fbf806a7000 ) at
../../exa/exa_accel.c:1198
pixmaps = {{as_dst = 0, as_src = 1, pPix = 0x1da4480, pReg =
0x7fff101aab80}}
Reg = {extents = {x1 = 0, y1 = 0, x2 = 21, y2 = 15}, data = 0x0}
pPix = value optimized out
xoff = value optimized out
yoff = value optimized out
ok = value optimized out
#8 0x004def9d in miSpriteGetImage (pDrawable=0x1da4480, sx=0, sy=0,
w=21, h=15, format=2, planemask=4294967295, pdstLine=0x7fbf806a7000 ) at
../../mi/misprite.c:354
pScreen = 0x12b3eb0
pDev = 0x0
pCursorInfo = value optimized out
#9 0x0050d844 in ProcShmGetImage (client=0x4b5e080) at
../../Xext/shm.c:969
pDraw = 0x1da4480
lenPer = 0
length = 140460469940224
plane = 0
xgi = {type = 1 '\001', depth = 24 '\030', sequenceNumber = 14619,
length = 0, visual = 0, size = 1260, pad0 = 91857776, pad1 = 0, pad2 =
19974240, pad3 = 0}
shmdesc = 0x1da3f70
rc = value optimized out
#10 0x0050e288 in ProcShmDispatch (client=0x4b5e080) at
../../Xext/shm.c:1125
No locals.
#11 0x0044d374 in Dispatch () at ../../dix/dispatch.c:437
result = value optimized out
client = 0x4b5e080
nready = 0
start_tick = 10660
#12 0x0043321d in main (argc=8, argv=0x7fff101aafb8, envp=value
optimized out) at ../../dix/main.c:397
i = 1
alwaysCheckForInput = {0, 1}
--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533444: xserver-xorg-video-ati: X server hang while starting opengl application
Henri Valta wrote:
Same problem (hang+kernel oops) with libdrm2 downgraded to 2.4.11-1
Previous report had libdrm2 2.4.11+git+20090519+f355ad8-1
Which drm kernel module are you running in both cases?
IIRC, we've seen some reports of kernel oops with recent radeon drm modules.
Brice
Changing AccelMethod to exa produces following gdb backtrace (now using
downgraded libdrm2)
Program received signal SIGINT, Interrupt.
0x7fbfa7d1e087 in ioctl () from /lib/libc.so.6
#0 0x7fbfa7d1e087 in ioctl () from /lib/libc.so.6
No symbol table info available.
#1 0x7fbfa67d7623 in drmIoctl (fd=10, request=25668, arg=0x0) at
../../libdrm/xf86drm.c:187
ret = 15
#2 0x7fbfa67d7926 in drmCommandNone (fd=10, drmCommandIndex=value
optimized out) at ../../libdrm/xf86drm.c:2313
No locals.
#3 0x7fbfa5d09cf4 in RADEONDownloadFromScreenCP (pSrc=value optimized
out, x=0, y=15, w=21, h=0, dst=0x1da44c0 P, dst_pitch=84) at
../../src/radeon_exa_funcs.c:411
oldhpass = value optimized out
i = 117
hpass = 0
scratch_pitch_offset = 12061448
indirect = {idx = 0, start = 0, end = 0, discard = 0}
__head = value optimized out
pScrn = 0x12a0820
src =
0x7fbf9358
\b\b\bFF\b\b\bFF\b\b\bFF\b\b\bFFhhhFF\215\220\220FF\215\220\220FF\215\220\220FFA0A0A0FFB2B5B5FFC5CACAFFC5CACAFFC8D4D8FFC8D4D8FFD0D9DDFFC8D4D8FFD0D4D8FFD0D4D8FFD0D4D8FFD0D4D8FFC5CCCDFFC5CCCDFFB2B8BAFFA0A4A8FF\210\216\215FF\210\216\215FF`d`FF`d`FFHIJFFHIJFF
bpp = value optimized out
datatype = 6
src_pitch_offset = 11940080
scratch_pitch = 128
scratch_off = 0
scratch = 0x12e7a70
#4 0x7fbfa544a2e9 in exaCopyDirty (migrate=0x7fff101aab60,
pValidDst=0x1da3f40, pValidSrc=value optimized out, transfer=0x7fbfa5d09750
RADEONDownloadFromScreenCP, fallback_src=
0x7fbf9e07c000
\002\002\002\002\006\006\006\027\a\a\a\031\a\a\a\031\a\a\a\031\a\a\a\031\a\a\a\031\006\006\006\027\002\002\002\b\b\b\bl,
fallback_dst=0x1da44c0 P, fallback_srcpitch=128,
fallback_dstpitch=84, fallback_index=1, sync=0x7fbfa590
exaWaitSync)
at ../../exa/exa_migration.c:210
pPixmap = 0x1da4480
pExaPixmap = 0x1da3f00
damage = value optimized out
CopyReg = {extents = {x1 = 0, y1 = 0, x2 = 21, y2 = 15}, data = 0x0}
save_offscreen = 1
save_pitch = 128
pBox = 0x7fff101aa9a0
nbox = 0
access_prepared = 0
need_sync = 0
#5 0x7fbfa544a620 in exaDoMoveOutPixmap (migrate=0x7fff101aab60) at
../../exa/exa_migration.c:258
pPixmap = 0x1da4480
#6 0x7fbfa544ad47 in exaDoMigration (pixmaps=0x7fff101aab60, npixmaps=1,
can_accel=0) at ../../exa/exa_migration.c:679
pExaScr = 0x12e74c0
i = 1
j = value optimized out
__func__ = exaDoMigration
#7 0x7fbfa5446c8a in exaGetImage (pDrawable=0x1da4480, x=0, y=0, w=21,
h=15, format=2, planeMask=4294967295, d=0x7fbf806a7000 ) at
../../exa/exa_accel.c:1198
pixmaps = {{as_dst = 0, as_src = 1, pPix = 0x1da4480, pReg =
0x7fff101aab80}}
Reg = {extents = {x1 = 0, y1 = 0, x2 = 21, y2 = 15}, data = 0x0}
pPix = value optimized out
xoff = value optimized out
yoff = value optimized out
ok = value optimized out
#8 0x004def9d in miSpriteGetImage (pDrawable=0x1da4480, sx=0, sy=0,
w=21, h=15, format=2, planemask=4294967295, pdstLine=0x7fbf806a7000 ) at
../../mi/misprite.c:354
pScreen = 0x12b3eb0
pDev = 0x0
pCursorInfo = value optimized out
#9 0x0050d844 in ProcShmGetImage (client=0x4b5e080) at
../../Xext/shm.c:969
pDraw = 0x1da4480
lenPer = 0
length = 140460469940224
plane = 0
xgi = {type = 1 '\001', depth = 24 '\030', sequenceNumber = 14619,
length = 0, visual = 0, size = 1260, pad0 = 91857776, pad1 = 0, pad2 =
19974240, pad3 = 0}
shmdesc = 0x1da3f70
rc = value optimized out
#10 0x0050e288 in ProcShmDispatch (client=0x4b5e080) at
../../Xext/shm.c:1125
No locals.
#11 0x0044d374 in Dispatch () at ../../dix/dispatch.c:437
result = value optimized out
client = 0x4b5e080
nready = 0
start_tick = 10660
#12 0x0043321d in main (argc=8, argv=0x7fff101aafb8, envp=value
optimized out) at ../../dix/main.c:397
i = 1
alwaysCheckForInput = {0, 1}
--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533444: xserver-xorg-video-ati: X server hang while starting opengl application
On Wednesday 17 June 2009 23:44:05 Brice Goglin wrote: Henri Valta wrote: Same problem (hang+kernel oops) with libdrm2 downgraded to 2.4.11-1 Previous report had libdrm2 2.4.11+git+20090519+f355ad8-1 Which drm kernel module are you running in both cases? In both cases I was running radeon drm module from linux-image-2.6.30-trunk- amd64 2.6.30-1~experimental.1~snapshot.13813 I also tried linux-image-2.6.30-1-amd64 2.6.30-1which produced almost exactly the same gdb trace and oops. linux-image-2.6.29-2-amd64 2.6.29-5 however produced slightly different oops (gdb trace was the same): [ 218.565299] BUG: unable to handle kernel NULL pointer dereference at (null) [ 218.565306] IP: [a04bb9f4] radeon_do_cp_idle+0x186/0x1ba [radeon] [ 218.565316] PGD 5a1ec067 PUD 718cc067 PMD 4c048067 PTE 0 [ 218.565320] Oops: [#1] SMP [ 218.565322] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor [ 218.565324] CPU 0 [ 218.565326] Modules linked in: radeon drm kvm_amd kvm powernow_k8 cpufreq_userspace cpufreq_conservative cpufreq_stats cpufreq_powersave nfsd exportfs nfs lockd nfs_acl auth_rpcgss sunrpc ipv6 fuse loop snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss s626(C) snd_pcm comedi_fc(C) comedi(C) snd_seq_dummy snd_seq_oss snd_seq_midi ves1820 snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device budget budget_core saa7146 snd soundcore ttpci_eeprom snd_page_alloc dvb_core i2c_viapro i2c_core psmouse shpchp joydev k8temp pci_hotplug evdev pcspkr serio_raw parport_pc parport button ext4 mbcache jbd2 crc16 sd_mod crc_t10dif usbhid hid ide_cd_mod cdrom ata_generic usb_storage ide_pci_generic sata_via uhci_hcd libata ehci_hcd via82cxxx ide_core scsi_mod atl1 mii thermal processor fan thermal_sys [ 218.565376] Pid: 4696, comm: Xorg Tainted: G C 2.6.29-2-amd64 #1 M2V [ 218.565378] RIP: 0010:[a04bb9f4] [a04bb9f4] radeon_do_cp_idle+0x186/0x1ba [radeon] [ 218.565385] RSP: 0018:880074c8bc28 EFLAGS: 00010202 [ 218.565387] RAX: RBX: 8800775ef000 RCX: 0002f69d [ 218.565389] RDX: 0002f69d RSI: 0003 RDI: 8800775ef000 [ 218.565390] RBP: 88007d8f6800 R08: R09: 88000101a500 [ 218.565392] R10: 8800764dd500 R11: 8034e5e9 R12: 880074d0a428 [ 218.565394] R13: 8800764dd500 R14: 88007d0f1ec0 R15: [ 218.565397] FS: 7f78ee00b7b0() GS:806c1000() knlGS:1823fb90 [ 218.565399] CS: 0010 DS: ES: CR0: 8005003b [ 218.565400] CR2: CR3: 7c5bb000 CR4: 06e0 [ 218.565402] DR0: DR1: DR2: [ 218.565404] DR3: DR6: 0ff0 DR7: 0400 [ 218.565407] Process Xorg (pid: 4696, threadinfo 880074c8a000, task 8800775b6660) [ 218.565408] Stack: [ 218.565409] 8800775ef000 a04bc599 80479fb0 0008 [ 218.565412] 88007d8f6800 a0491e3e 88007690bc80 0008 [ 218.565416] 88007690bc80 880074d0a428 8800764dd500 802be27a [ 218.565420] Call Trace: [ 218.565422] [a04bc599] ? radeon_do_release+0x4e/0x13b [radeon] [ 218.565428] [80479fb0] ? unlock_kernel+0x2b/0x2d [ 218.565432] [a0491e3e] ? drm_lastclose+0x40/0x28d [drm] [ 218.565451] [802be27a] ? __fput+0xc6/0x16e [ 218.565455] [802bb9a4] ? filp_close+0x5b/0x62 [ 218.565459] [802453e5] ? put_files_struct+0x64/0xc2 [ 218.565462] [80479d51] ? _spin_lock_irq+0xd/0xf [ 218.565465] [80246d5d] ? do_exit+0x1ea/0x7b1 [ 218.565467] [80258aa3] ? ktime_get_ts+0x21/0x4a [ 218.565471] [80211f8e] ? reschedule_interrupt+0xe/0x20 [ 218.565474] [80247397] ? do_group_exit+0x73/0x9f [ 218.565476] [8024fd2b] ? get_signal_to_deliver+0x315/0x33e [ 218.565479] [8021034a] ? do_notify_resume+0x85/0x7cf [ 218.565483] [8023788e] ? set_next_entity+0x34/0x56 [ 218.565486] [8023f8a3] ? finish_task_switch+0x2a/0xc7 [ 218.565490] [804789f5] ? thread_return+0x3d/0xd4 [ 218.565494] [802111ee] ? sysret_signal+0x96/0xff [ 218.565497] Code: 28 0f ae f0 83 bb 80 00 00 00 00 74 0d 48 8b 83 20 01 00 00 48 8b 40 18 eb 11 48 8b 83 f8 03 00 00 48 8b 40 18 48 05 10 07 00 00 8b 00 48 8b 83 f8 03 00 00 8b 53 28 48 8b 40 18 48 05 14 07 00 [ 218.565520] RIP [a04bb9f4] radeon_do_cp_idle+0x186/0x1ba [radeon] [ 218.565526] RSP 880074c8bc28 [ 218.565527] CR2: [ 218.565529] ---[ end trace 1d65bdc6a8c8773a ]--- [ 218.565531] Fixing recursive fault but reboot is needed! -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533444: xserver-xorg-video-ati: X server hang while starting opengl application
On Thu, Jun 18, 2009 at 2:06 AM, Henri Valtac...@jakorasia.info wrote: Package: xserver-xorg-video-ati Version: 1:6.12.2-2 Severity: normal Xserver hangs and becomes unkillable using 100% CPU while starting certain opengl applications. This report is generated from starting a 3D game with wine. The hang is reproducable and almost immediate with this app. This is the X server backtrace generated with gdb by pressing CTRL-C during the hang This is a pretty standard GPU hang. I'd suggest trying a newer ddx and mesa 3d driver. Alex -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
