Printable View
It might be a cooling problem - it's because desktop effects use more of the GPU power all the time. In my case after running for few hours KDE4 with desktop effects and now I start Nexuiz I can get freeze after few seconds (sometimes I can do SysRQ sometimes not) but when I just start my computer and then start Nexuiz I can play the game without problems for few hours. One time I've noticed image dissortion in Firefox and some minutes later a freeze.Quote:
Originally Posted by f0x_
i have strange problem with my 9700 mobility. when i use compiz, i don't have freeze, when i use metacity, after 2-3 minutes, pc freeze and i must force power off. in my xorg.log i have this:
[2273 sec: 110791 usec](II) RADEON(0): [RESUME] Attempting to re-init Radeon hardware.
[2273 sec: 110850 usec](**) RADEON(0): Using AGP 4x
[2273 sec: 110899 usec](II) RADEON(0): [agp] Mode 0x1f000207 [AGP 0x8086/0x3340; Card 0x1002/0x4e50 0x1734/0x106b]
For those of you having lockup or corruption problems does this patch help?
http://www.botchco.com/alex/xorg/rad...gine_idle.diff
@agd5f: Maybe this is related to horrible way how mesa dri drivers are writen. I just noticed the there is huge amount of debug output inside drm lock. That means for me that if I have that debug output going to terminal my system had high chance of freeze. Easy way to reproduce that with r200 is doing R200_DEBUG=all glxgears
I did code a work around so that this blocking operation is detected and any program would crash. MY code to do it was that I added to r200_lock.c/h 2 functions. setAlarm() and freeAlarm() that I canlled just after acquiring the lock and just before releasing. setAlarm() did settup SIGALRM handler when it was first time called and everytime called alarm(1). freeAlarm() did just call alarm(0). Signal handler just called abort().
That way I could get coredump from freeze. Of course I know that this isn't going to be general purpose debugging way because of limitations in alarm but maybe something similar could be done with timers so it won't interfere with application code.
Just a warning: DON'T do local debugging using gdb with this trick. It is going to freeze X also. Remote debugging using ssh works fine.
+1
I quite occasionally notice this maybe 3 years ago. Tried to debug some fallbacks with R200_DEBUG=fall, do a typo and X just freeze.
If you have problems with heat DynaimicClocks might help you
man radeon says:
Option "DynamicClocks" "boolean"
Enable dynamic clock scaling. The on-chip clocks will scale dynamically based on usage. This can help
reduce heat and increase battery life by reducing power usage. Some users report reduced 3D performance
with this enabled. The default is off.
Should I Still try this one? I've seen that you reverted this patch in your repository.Quote:
Originally Posted by agd5f
By the way, there seems to be a new problem. Sometimes, XV output crashes X. I can play five, six movies after another and the seventh makes X restart after about one or two seconds. Happens both with "classic" overlay and Textured Video.
I can confirm that my lockup issues still persist with the 6.11.0 driver. I'll try agd5fs patch and report back.
Note that when my system enters this lockup-mode, I can still SSH into it - upon attaching gdb to it, it consistently gives the following backtrace:
#0 0x00007ff2b9c7c777 in ioctl () from /lib/libc.so.6
#1 0x00007ff2b8953b15 in drmDMA () from /usr/lib/libdrm.so.2
#2 0x00007ff2b80621de in RADEONCPGetBuffer (pScrn=0x7fe9b0) at radeon_accel.c:593
#3 0x00007ff2b8062370 in RADEONCPFlushIndirect (pScrn=0x7fe9b0, discard=1) at radeon_accel.c:647
#4 0x00007ff2b80ab4a8 in RADEONPrepareSolidCP (pPix=<value optimized out>, alu=3, pm=4294967295, fg=3432552600) at radeon_exa_funcs.c:103
#5 0x00007ff2b77ea528 in ?? () from /usr/lib64/xorg/modules//libexa.so
#6 0x00007ff2b77eae4b in ?? () from /usr/lib64/xorg/modules//libexa.so
#7 0x00000000005201f4 in ?? ()
#8 0x0000000000508fc1 in miCompositeRects ()
#9 0x0000000000510581 in ?? ()
#10 0x0000000000449654 in Dispatch ()
#11 0x00000000004314ba in main ()
This is a GPU lockup. The engine has hung and is no longer processing dma buffers so the fences never come up and the buffers can't be freed and the driver keeps querying for free dma buffers.Quote:
Originally Posted by DuSTman
I did a git bisect on this issue - the results:
0d5e0347af4322713075193154b8a348de4a0b52 is first bad commit
commit 0d5e0347af4322713075193154b8a348de4a0b52
Author: Alex Deucher <alexdeucher@gmail.com>
Date: Wed Aug 13 14:17:34 2008 -0400
Remove reset of 3D scissor registers when using the CP in the ddx
They should only affect 3D and init3d() should take care of that case
noticed by libv on IRC.
:040000 040000 628f00b2656f9697532fbbc31d17f508c483622a c8794ffeeae7823dd45c27e6aada97ff21826ca M src
I don't know how many other people here are affected by this (I get the feeling different people in this thread are encountering slightly different bugs).
For reference, my hardware is a Radeon x850 - kernel is 2.6.27-gentoo-r7