Drivers for linux are rubbish

[ahhyes]

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.

[ahhyes]

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.

[rohcQaH]

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

[adamk]

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

[ahhyes]

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.

[ahhyes]

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.

[ahhyes]

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.

[adamk]

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/catalyst/catalyst/fglrx-2.6.33.patch

[adamk]

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

[damentz]

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.