Announcement

Collapse
No announcement yet.

Warning to users of Catalyst 8.11

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

  • Warning to users of Catalyst 8.11

    On 64-bit Gentoo, with X.Org 7.4 (XServer 1.5.3) and kernels 2.6.26 and 2.6.27, running on Catalyst 8.11 (ati-drivers-8.552-r2) results in data corruption that sometimes manifests in segfaulting application. emerging not-so-small applications (mozilla-thunderbird) has gcc, as (assembler) and python segfault at times. That is, if you're lucky. If you're not lucky, broken machine code can be produced without you ever knowing, fscking up your whole system.

    Everything went stable again after reverting back to xf86-video-radeonhd.

    So I guess I can say "you have been warned" here. Do thorough tests to see if you're affected by this if you want to use Catalyst 8.11 since this is serious.

  • #2
    Maybe I was lucky. I haven't met any segfault since I installed ati-drivers-8.552-r2.

    The only thing I'm complaining about ati-drivers-8.552-r2 is that I still have no luck getting crossfire enabled on my ATI 4870x2.

    By the way. AIGLX has been enabled successfully after I installed libstdc++-v3 package
    There used to be some error messages in my /var/log/Xorg.0.log:
    Code:
    (EE) AIGLX error: fglrx exports no extensions (/usr/lib64/dri/fglrx_dri.so:
    undefined symbol: __driDriverExtensions)
    (EE) AIGLX: reverting to software rendering
    Installing libstdc++-v3 and re-emerging ati-drivers solved the problem.

    Comment


    • #3
      Stress test your system before making an assumption. Like a kernel or OpenOffice compile. I don't have crashes either otherwise.

      Comment


      • #4
        Any other reports of this happening to others, or is it just one user?

        OP, better make sure you have all the latest libs and latest stable GCC installed for your system...maybe you might have some libs that are outdated.

        Comment


        • #5
          8.11 is the most stable driver ever. Even better than all the nvidia drivers I enjoyed over the years.

          But you have to give the 'nopat' option at the kernel command line.

          Comment


          • #6
            I have the same config (Gentoo 64-bit, xorg-server-1.5.3, kernel-2.6.27 and ati-drivers-8.552-r2). I compiled a crossdev gcc, firefox, xulrunner, etc, and using the system under heavy load (virtualbox + eclipse) and have zero problems. Maybe you have a filesystem/hardware issue.

            Comment


            • #7
              Originally posted by RealNC View Post
              On 64-bit Gentoo, with X.Org 7.4 (XServer 1.5.3) and kernels 2.6.26 and 2.6.27, running on Catalyst 8.11 (ati-drivers-8.552-r2) results in data corruption that sometimes manifests in segfaulting application. emerging not-so-small applications (mozilla-thunderbird) has gcc, as (assembler) and python segfault at times. That is, if you're lucky. If you're not lucky, broken machine code can be produced without you ever knowing, fscking up your whole system.

              Everything went stable again after reverting back to xf86-video-radeonhd.

              So I guess I can say "you have been warned" here. Do thorough tests to see if you're affected by this if you want to use Catalyst 8.11 since this is serious.
              You are not alone. I am also on gentoo amd64 with a 790gx based MB kernel 2.6.27-7. I reverted to 7.3/8.542 since my box was dieing. I would need to install a serial console to see if it was a panic or stall. It did not take much to cause the new x/driver combo to kill the system. Just moving around a kterm eventually would trigger a crash. Here 7.4/8.552/gcc 4.3.2 makes for a very unstable system.

              I have had small issues with 8.542 where X stalls. I have always been able to recover by sshing from another box and killing X. Ssh is not working when 8.552 bugs out. On the positive side its 25% faster...

              The thread "Locking issues with Catalyst 8.11" looks to describe something very similar to my report. Which makes three of us with the problem. Guess I will go buy a serial card tomorrow and try to get the opps/panic/stall recorded.
              Last edited by eddt; 11-21-2008, 10:28 PM.

              Comment


              • #8
                Some Gentoo people deliberately sabotage Gentoo. You are left to figure out their motives.

                This Catalyst thing might not be deliberate, but it would be worth checking to see.

                Some Gentoo folk have clearly sabotaged Reiser3:

                I would have usually formated /dev/hdb3 with the Reiser3 filesystem, however, this usually extremely reliable filesystem, has been deliberately sabotaged. This sabotage causes massive corruption of files after a short time. By comparison, I have used the Reiser3 filesystem for nearly ten years now and have never had any corruption, at all, on any of my many Reiser3 boxes.

                From: http://linux.50webs.org/gentoo/qemu-gentoo.htm
                Some folk have also clearly sabotaged Reiser4. See; The Linux Kernel SABOTEURS.

                http://linux.50webs.org/jews/saboteurs.htm
                http://www.phoronix.com/forums/showthread.php?t=9509
                Last edited by Jade; 11-22-2008, 07:04 AM.

                Comment


                • #9
                  Yes, they're SD-6 double agents.

                  Seriously, I have this problem, and only with 8.11. I never claimed this to be a bug that affected others, only me, but because on my system it's a serious one, I felt obligated to post here so others can check if they're affected. Do a bit of stress testing, and if you're fine, then I'd say no reason for panic.

                  PS:
                  As to whether I'm using outdated libs, well, I'm on Gentoo so no. Nothing is outdated. But perhaps this might be a problem since AMD/ATI historically supported distros with outdated stuff.
                  Last edited by RealNC; 11-22-2008, 07:29 AM.

                  Comment


                  • #10
                    em, if you are using stable some libs might be pretty old. Also just -u system and -u world does not cover everything.

                    And hey, I just got news from a nvidia using friend. The latest driver completly fucked up his fonts ....

                    maybe your hardware is just broken - but the new driver make the bugs appear more readily?

                    Comment


                    • #11
                      I can only agree with RealNC on this, 8.11 fucked up my system baaadly. I've got pretty much the same setup (Gentoo x86_64, Kernel 2.6.27,X Server 1.5.3), but I've experienced different problems:
                      When using fglrx things were mostly okay, but radeon stopped working completely. I couldn't even startx with radeon anymorge (drm and radeon modules loaded, fglrx unloaded, symlinks setup correctly, and correct xorg.conf. Still X simply wouldn't start). Now that I unmerged ati-drivers, X atleast starts again, but everythings just awkward... (don't know how to describe more precisely... well, system is sluggish, and e.g. my taskbar symbols are messed up. and compositing isn't working anymore).
                      I'm now reemerging radeon, mesa, my drm-modules etc and hope this will fix things.
                      So yeah I'd suggest everyone to be really carefully with Catalyst 8.11 on Gentoo. I guess the ebuild is bugged...

                      Comment


                      • #12
                        Zhick, I think your problems are caused by the Gentoo ati-drivers ebuild, not the Catalyst driver. See http://bugs.gentoo.org/show_bug.cgi?id=246672#c47. If I'm right, re-emerging xorg-server should fix your problems, at least as long as you don't reinstall ati-drivers-8.552-r2.

                        Comment


                        • #13
                          you probably installed the wrong ebuild - composite broken is a sign of mismatch and missing fglrx libglx.
                          emerge -C ati-drivers && emerge "=ati-drivers-8.552-r2"

                          Comment


                          • #14
                            Nope, 8.552-r2 was definitly the version I installed.
                            And I'm not gonna touch that driver again until I've fixed my precious radeon setup... reemerging mesa, radeon, drm and libdrm didn't fix it... I'm using vesa right now. I'm gonna emerge -e @system && emerge -e @world now : /.

                            Comment


                            • #15
                              instead of senseless re-emerging, you should check which packet installs which files and compare that. Well done it only takes a minute or two and always leads to meaningfull results. If somewhere is a stale libglx or something like that, emerging stuff won't help you.

                              And in the future: stay away from unstable stuff, if you can't cope with the problems.

                              Comment

                              Working...
                              X