Announcement

Collapse
No announcement yet.

Drivers for linux are rubbish

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

  • Drivers for linux are rubbish

    Seriously, whats up with AMD? I am always able to install nvidia's drivers fine, never a problem. With with the ATI drivers, constant fglrx build issues, kernel incompatibilities:

    So here we go again, I download ati-driver-installer-10-5-x86.x86_64.run after upgrading my kernel to 2.6.34, surprise surprise, ATI *still* hasn't realized that in the kernel source tree include/linux/utsrelease.h (and a number of other files have been moved to ../generated

    this change occurred quite a while ago in the linux kernel source tree, but AMD don't seem to give a toss, of course the compilation of fglrx fails because its looking for these files in the wrong place. So after spending time and creating symlinks in the source tree to work around AMD's stupidity, fglrx still wont build.

    make[2]: Entering directory `/usr/src/linux-2.6.34'
    CC [M] /usr/src/fglrx-8.732/2.6.x/firegl_public.o
    In file included from /usr/src/fglrx-8.732/2.6.x/firegl_public.c:443:
    /usr/src/fglrx-8.732/2.6.x/drm_proc.h: In function ‘FGLDRM__vma_info’:
    /usr/src/fglrx-8.732/2.6.x/drm_proc.h:497: warning: format ‘%08lx’ expects type ‘long unsigned int’, but argument 5 has type ‘phys_addr_t’
    /usr/src/fglrx-8.732/2.6.x/firegl_public.c: In function ‘KCL_SetPageCache_Array’:
    /usr/src/fglrx-8.732/2.6.x/firegl_public.c:1316: warning: passing argument 1 of ‘KCL_ConvertPageToKernelAddress’ makes pointer from integer without a cast
    /usr/src/fglrx-8.732/2.6.x/firegl_public.c: In function ‘__ke__cmpxchg’:
    /usr/src/fglrx-8.732/2.6.x/firegl_public.c:1473: error: variable or field ‘__ret’ declared void
    /usr/src/fglrx-8.732/2.6.x/firegl_public.c:1473: error: variable or field ‘__old’ declared void
    /usr/src/fglrx-8.732/2.6.x/firegl_public.c:1473: error: variable or field ‘__new’ declared void
    /usr/src/fglrx-8.732/2.6.x/firegl_public.c: In function ‘KCL_MapPageToPfn’:
    /usr/src/fglrx-8.732/2.6.x/firegl_public.c:1615: warning: unused variable ‘bus_addr’
    make[3]: *** [/usr/src/fglrx-8.732/2.6.x/firegl_public.o] Error 1
    make[2]: *** [_module_/usr/src/fglrx-8.732/2.6.x] Error 2
    make[2]: Leaving directory `/usr/src/linux-2.6.34'
    make[1]: *** [kmod_build] Error 2
    make[1]: Leaving directory `/usr/src/fglrx-8.732/2.6.x'
    build failed with return value 2
    make: *** [all] Error 1
    PATHETIC.

    The other thing is also, if you do not set MALLOC_CHECK_=0 before running the installer, the installer crashes during the fglrx build.

    Why do they make it so difficult? I've been from kernel 2.6.32, .33, .34 and never had an nvidia driver install go bad. It just always seems to be with ATI i am forever stuffing around to get their drivers to install.

    So, is there another patch to fix this fglrx issue with 2.6.34 kernels?

    Sorry for the rant, but I am so sick to death of constantly running into the same issues with ATI drivers on linux.

  • #2
    ati, the linux world has moved forward since kernel 2.6.28, update your flamin install scripts and fglrx code so it can cope with modern kernels.

    Comment


    • #3
      duh, why do you keep upgrading to kernel versions which are clearly not supported by the drivers yet? You're asking for pain.

      It's a well known fact that ATI doesn't start supporting newer kernels until they're used by one of their supported distros. That's not incompetence as you suggest, that's a matter of priorities. You obviously don't like it, but ranting won't change anything about that.


      Of course there's always the OS drivers if you need first-day-support on any released kernel..

      Comment


      • #4
        For what it's worth, fglrx 10.5 works here with kernel 2.6.34 once I apply the two patches that you can find in various places on the internet, including this very forum.

        Adam

        Comment


        • #5
          Originally posted by adamk View Post
          For what it's worth, fglrx 10.5 works here with kernel 2.6.34 once I apply the two patches that you can find in various places on the internet, including this very forum.

          Adam
          Hi Adam,

          Do you have a link for these patches? I just dont fancy reading through 900 pages and threads to find em.

          Comment


          • #6
            Originally posted by rohcQaH View Post
            duh, why do you keep upgrading to kernel versions which are clearly not supported by the drivers yet? You're asking for pain.

            Of course there's always the OS drivers if you need first-day-support on any released kernel..
            It's just silly though, the nvidia drivers and installer are coded so that they cope with modern kernels, this means they are better written.

            The 2.6.3X series kernels have been around for quite a while now, the move of utsrelease.h (and a few other header files) to the "generated" directory in the linux kernel source tree happened ages ago. Why is it unreasonable to expect that ATI can make some code in the driver to cope with this. It's easy to solve, but the coders are too lazy:

            Logic:

            if (kernel version >= version where change were made to files in kernel source)
            {
            auto apply a patch which corrects the #include statements in the code
            }
            else
            {
            don't apply the patch
            }

            Why is it the nvidia drivers dont have this problem. Infact I have had custom kernel versions that are numerous major versions that is shipping with the stock distro kernel, and the nvidia drivers cope fine with building the kernel blob, it's worked every single time without hastle. I dont have to set MALLOC_CHECK_=0 with the nvidia driver install program, without specifying it, the ATI installer dies.

            I think ATI could learn a few things from nvidia how to construct drivers for linux.

            Only that the machine in question is not mine, it's fairly obvious what I would do about the video card if it was.

            Comment


            • #7
              Typical example:

              I installed kernel 2.6.34 on another system. I then installed a version of the nvidia driver that came out when 2.6.33 was just released, guess what? No hastles. That's why I am saying that the nvidia installer/driver code is better designed (more resilient).

              I had to add this extra post because the forum doesnt allow editing after 1 minute? :/

              Modeling the driver to work only around old kernels is poor form.

              Comment


              • #8
                Originally posted by ahhyes View Post
                Hi Adam,

                Do you have a link for these patches? I just dont fancy reading through 900 pages and threads to find em.
                I'm not in front of my slackware box or I would post both patches directly on my system, but I think this may be both of them combined:

                http://aur.archlinux.org/packages/ca...x-2.6.33.patch

                Comment


                • #9
                  Originally posted by ahhyes View Post
                  Modeling the driver to work only around old kernels is poor form.
                  They model the driver to work around supported distributions. That's the way it is and it's not likely to change any time in the near future. The wrapper code is open source so folks can do things like patch it to make it work on newer kernels (if the changes can be made in the wrapper code, of course. There's not much point in complaining.

                  I will point out, however, that a thread subject like "Drivers for linux are rubbish" isn't likely to get folks to want to help you get the drivers working, and very nearly stopped me from pointing out that patches *do* exist to get the driver working on 2.6.34.

                  Adam

                  Comment


                  • #10
                    AMD probably has less developers working on the Linux driver. Their development is basically, fix it when it breaks. nVidia probably looks for signs of deprecation and fixes kernel bugs early. The only problems they get are things that are changed silently while fglrx doesn't work anyway.

                    I like to compare it to backing up a disk daily and replacing the drive when there are signs of new unreliability.

                    AMD seems to be the type that waits for the drive to stop writing and reading reliability, take the system down, send off their drive to the nearest recovery plant, and one month later you can begin using your server once all the data has been recovered.

                    That's the life you get when you use the newest stable kernel with AMD's Linux drivers.

                    Comment


                    • #11
                      Originally posted by damentz View Post
                      AMD probably has less developers working on the Linux driver. Their development is basically, fix it when it breaks. nVidia probably looks for signs of deprecation and fixes kernel bugs early. The only problems they get are things that are changed silently while fglrx doesn't work anyway.

                      I like to compare it to backing up a disk daily and replacing the drive when there are signs of new unreliability.

                      AMD seems to be the type that waits for the drive to stop writing and reading reliability, take the system down, send off their drive to the nearest recovery plant, and one month later you can begin using your server once all the data has been recovered.

                      That's the life you get when you use the newest stable kernel with AMD's Linux drivers.
                      ^^^^^ x1000!!!! if you are stuck with a laptop with an ATI card in it.

                      I wouldn't buy any new laptop with an ATI card in it!

                      At least, on the desktop, you have options... 'can experiment with an ATI card and if you're unsatisfied, you have options.

                      Comment


                      • #12
                        So this is where the trolls have all gone!

                        Comment


                        • #13
                          I would like to say, that my choice for next laptop four months ago was Intel + ATI! And this was due to nVidia not solving power management problems with my previous laptop. I had really hard time with them, especially powermizer not changing levels fast enough but mainly this was due to stupid beeps, long waits when resuming from hibernate. More then 2 minutes were spent just on nothing, laptop was dead not doing anything - black screen, no HDD leds blinking and it beeps 3 times in between for no reason, kernel logs were reporting some spinlocks or so... And that was happening for period of 2 years. I had written long posts on nvnews, tried countless workarounds and nothing helped till the day I just received this new laptop with ATI, the lucky day

                          And guess what, no problems with powermizer, no problems with power management at all, hibernates are fast, suspend works, opengl is good, multiple monitors works, everything I need JUST WORKS like a charm! I would never go back to nVidia for laptop unless they show me that there are no problems with PM and proove me that ATI sucks
                          One thing that doesn't work for me is fast user switching, it just dies when second session is logged out

                          So, please get patches and don't act like trolls...
                          Also, I'm kinda lucky using ArchLinux, as there is AUR which does build catalyst with patches for me, I don't have to do anything by hand
                          I wish ATI to continue improving things...

                          Comment


                          • #14
                            if you are such a noob that you can not follow the threads and postings everywhere that you have to patch something, you are too much of a noob to use anything but a distro kernel.

                            Comment


                            • #15
                              Grab and run http://kanotix.com/files/install-fglrx-debian.sh to avoid worrying about these issues, but you have to be running (preferably) Kanotix, or Debian, or Ubuntu. It might work on derivatives like Mint, too. AFAIK it's tested to some degree on Kanotix and the latest release of Ubuntu.

                              Note: the above script is by Phoronix member "Kano", who afaik is the lead developer of the Kanotix distro. Although he is vocal about many valid problems with fglrx, he also seems to have a great system in place for hacking the driver's open source bits to work with new kernels and userspaces. This is really a great thing, that we have someone making it easy for the rest of us.

                              Comment

                              Working...
                              X