Page 3 of 13 FirstFirst 12345 ... LastLast
Results 21 to 30 of 121

Thread: random X freeze with latest ati driver

  1. #21
    Join Date
    Aug 2007
    Location
    Poland
    Posts
    215

    Default

    Quote Originally Posted by f0x_ View Post
    It's not a cooling problem. In my opinion there's a bug related to (compiz, kde desktop effects) acceleration. I don't know how to file a bug report cause the freeze can't make me switch to console.
    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.

  2. #22
    Join Date
    Mar 2008
    Posts
    29

    Default

    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]

  3. #23
    Join Date
    Dec 2007
    Posts
    2,320

    Default

    For those of you having lockup or corruption problems does this patch help?

    http://www.botchco.com/alex/xorg/rad...gine_idle.diff

  4. #24
    Join Date
    Jan 2009
    Posts
    117

    Default

    @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.

  5. #25
    Join Date
    Feb 2008
    Posts
    759

    Default

    +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.

  6. #26
    Join Date
    Jan 2009
    Posts
    117

    Default

    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.

  7. #27
    Join Date
    Dec 2006
    Posts
    112

    Default

    Quote Originally Posted by agd5f View Post
    For those of you having lockup or corruption problems does this patch help?

    http://www.botchco.com/alex/xorg/rad...gine_idle.diff
    Should I Still try this one? I've seen that you reverted this patch in your repository.

    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.

  8. #28
    Join Date
    Jan 2009
    Posts
    86

    Default

    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 ()

  9. #29
    Join Date
    Dec 2007
    Posts
    2,320

    Default

    Quote Originally Posted by DuSTman View Post
    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.

  10. #30
    Join Date
    Jan 2009
    Posts
    86

    Default

    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •