Announcement

Collapse
No announcement yet.

random X freeze with latest ati driver

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    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.

    Comment


    • #22
      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]

      Comment


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

        Comment


        • #24
          @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.

          Comment


          • #25
            +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.

            Comment


            • #26
              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.

              Comment


              • #27
                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.

                Comment


                • #28
                  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 ()

                  Comment


                  • #29
                    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.

                    Comment


                    • #30
                      I did a git bisect on this issue - the results:

                      0d5e0347af4322713075193154b8a348de4a0b52 is first bad commit
                      commit 0d5e0347af4322713075193154b8a348de4a0b52
                      Author: Alex Deucher <[email protected]>
                      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

                      Comment

                      Working...
                      X