# ati-drivers and linux-2.6.6-mm2

## LinuxRocks

Hey all,

I just merged in the new (Out of ~x86) version of the MM-SOURCES (linux-2.6.6-mm2). I compiled it using a good config from the linux-2.6.6-rc3-mm1 (keyword ~x86) version that I had no problems with.

When I try to build my ati drivers, I doesnt build the glx module on the new kernel. Is there a broken feature in the kernel? Just thought I would let someone know... Here is the output for the ati-driver build:

```
* building the glx module

make: Entering directory `/usr/src/linux-2.6.6-mm2'

  CC [M]  /var/tmp/portage/ati-drivers-3.2.8-r1/work/lib/modules/fglrx/build_mod/agp3.o

  CC [M]  /var/tmp/portage/ati-drivers-3.2.8-r1/work/lib/modules/fglrx/build_mod/nvidia-agp.o

  CC [M]  /var/tmp/portage/ati-drivers-3.2.8-r1/work/lib/modules/fglrx/build_mod/agpgart_be.o

/var/tmp/portage/ati-drivers-3.2.8-r1/work/lib/modules/fglrx/build_mod/agpgart_be.c: In function `agp_generic_alloc_page':

/var/tmp/portage/ati-drivers-3.2.8-r1/work/lib/modules/fglrx/build_mod/agpgart_be.c:1405: error: structure has no member named `count'

make[1]: *** [/var/tmp/portage/ati-drivers-3.2.8-r1/work/lib/modules/fglrx/build_mod/agpgart_be.o] Error 1

make: *** [/var/tmp/portage/ati-drivers-3.2.8-r1/work/lib/modules/fglrx/build_mod] Error 2

make: Leaving directory `/usr/src/linux-2.6.6-mm2'

 * glx module not built

 * cleaning

nostrip

```

It runs fine on the older kernel, but I would like to get the current up to date one rather than using the older dev one inplace...

Thoughts?

Thanks

Joe

----------

## Wedge_

That's one of the risks you run in using newer kernels like mm-sources. It's not that the kernel is broken, but that some of the code has been changed by one of the patches it contains, and that in turn has stopped the ati-drivers from compiling properly because it depends on the same code. Nothing much you can do except try a different kernel, unless you want to try fixing the problem yourself (sometimes it can be a fairly simple fix).

----------

## Admiral LSD

After a fair bit of messing around I've managed to figure out the problem here: The kernel part of the ATi drivers uses the page->count struct which has been deprecated and cleaned up/replaced as of -mm2. The fix seems simple enough: Change all the instances of page->count in the driver to the newer version but while I *think* I've managed to do that in the agpgart_be.c file I have no idea what to make of this in the firegl_public.c file:

 *Quote:*   

> atomic_inc(&(pMmPage->count));

 

None of the examples I was working of (equivalent changes in other parts of the kernel) had anything like it so I have no idea what to replace it with.

----------

## LinuxRocks

I do appreceate your looking into this. Should I submit a bug report somewhere? I'm still kind of new to this kernel building stuff, and usually it just works. Never had a problem before with a Linux kernel. If they are removing features from the kernel that most people are going to need (At least ATI users), then a bug report is in order I would imaging. 

Anyway, thanks for looking into this. Must get to work. Let me know if I should put in a bug report and I will. It will be my first  :Very Happy: 

Thanks again

Joe

----------

## Gentii

ati and nvidia suck with their binary drivers, just burn their cards   :Smile: 

----------

## Wedge_

It's not really a kernel problem. From what Admiral LSD has said, some of the code in the kernel is being replaced and improved in this version of -mm. At some point, all being well, it will be merged into the main tree. Then ATI will need to update their drivers to keep up with those changes in the kernel. Remember that with all the different kernel versions out there, it's pretty difficult for them to produce a driver version compatible with every kernel (there are patches floating around for the nVidia drivers too), especially the really up to date kernels like -mm or -love with a bunch of new stuff in them, and as I said, this can result in the driver failing to compile against certain kernels. What you could do is produce a patch for these changes, and submit it to bugs.gentoo.org. It might then get added to the driver ebuild where it can get applied automatically, but I'd imagine that would depend on whether or not it's going to affect a lot of users, or if it would cause problems with older kernels etc.

----------

## Wedge_

I made a little patch for the driver to apply the changes Admiral LSD mentioned 

```
--- agpgart_be.c.orig   2004-05-14 21:39:19.943584512 +0000

+++ agpgart_be.c        2004-05-14 21:39:28.140338416 +0000

@@ -1402,7 +1402,7 @@ unsigned long agp_generic_alloc_page(voi

     }

 #endif

 

-    atomic_inc(&page->count);

+    get_page(page);

     set_bit(PG_locked, &page->flags);

     atomic_inc(&agp_bridge.current_memory_agp);

 

@@ -4413,7 +4413,7 @@ static unsigned long ali_alloc_page(void

     if (page == NULL)

         return 0;

 

-    atomic_inc(&page->count);

+        get_page(page);

     set_bit(PG_locked, &page->flags);

     atomic_inc(&agp_bridge.current_memory_agp);

 

--- firegl_public.c.orig        2004-05-14 21:38:53.296635464 +0000

+++ firegl_public.c     2004-05-14 21:40:28.492163544 +0000

@@ -2052,7 +2052,7 @@ static vm_nopage_ret_t vm_shm_nopage(str

     pMmPage = virt_to_page(kaddr);

 #endif /* LINUX_VERSION_CODE < 0x020400 */

 

-    atomic_inc(&(pMmPage->count));  /* inc usage count of page */

+    get_page(pMmPage);  /* inc usage count of page */

 

 #if LINUX_VERSION_CODE >= 0x020400

   //  __KE_DEBUG3("vm-address 0x%08lx => kernel-page-address 0x%p\n",
```

Save it somewhere, then edit the ebuild and add the line 

```
patch -p0 < /path/to/the/file
```

 inside the "if" statement on line 53, just after the "epatch". I'm not using 3.7.6, but I think it'll still apply properly. 

@Admiral LSD: according to K&R, the "->" operator has a higher precedence than "&", which should mean that "&(pMmPage->count)" is equivalent to "&pMmPage->count", so the fix is still the same.

----------

## Dinini

Probably a foolish question, why don't you reverse the suspect mm2 patch and verify that this fixes the problems before making patches to deal with the new behaviour?

```
wget -O - -q http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6/2.6.6-mm2/broken-out/page_count-fixups.patch | patch -p1 -R
```

----------

## Wedge_

Either way should work at the moment, but if the changes in -mm are going to be retained in future versions as the comment in the patch seems to imply:  *Quote:*   

> I'm about to change the meaning (and name) of page->count.  Go through and fix
> 
> up all those places which are open-coding references to it.

 

 and then eventually moved into the main tree, it seems a bit more sensible to fix the drivers rather than reverting changes to the kernel. Didn't someone in the love-sources thread check that reverting it worked anyway?

----------

## Admiral LSD

Reversing the page_count_fixups patch was one of the first things I tried. It had no effect other than to prevent the kernel compiling with the same error the ATi drivers did meaning the changes run a lot deeper than just that one patch. In the long term application level patches are the best solution.

Oh, and I tired the patch against 3.7.6 and all the hunks failed. I'm not quite sure why, patch is usually pretty good at fudging diffs that don't quite line up but perhaps the changes between 3.2.8 and 3.7.6 are a little greater than it can handle. At least I know what I'm looking for now so I'll make the changes manually and see what happens.

edit: turns out my quick copy and paste job did something funky with the file. Making a new file by quoting Wedge's post and copying from there instead of copying from thet thread directly seems to have worked for 3.2.8 but I haven't tried 3.7.6 yet. Will do that now.

edit2: SUCCESS! It patches against 3.7.6 just as well as 3.2.8 and the DRM module appears to compile.

----------

## Dinini

Just suggesting that the behaviour be confirmed before creating a patch (since that may only be part of the problem).   :Smile:  Not suggesting that a patch isn't needed.

----------

## Gentii

Thanks to  Wedge and LSD, you just rule   :Smile: 

----------

## coreutils

The patch makes the module compile in both mm2 and mm3 for me. It loads fine as well.

However glxinfo|grep direct returns "direct rendering no".

I'm sticking with love sources for now as they work with the module and are based on mm. I just don't use the bootsplash and supermount and what else bad code patches.

----------

## Anior

The patch applies on 3.7.6 and it's possible to build the module. However, I get this when I try to load it:

```
fglrx: module license 'Proprietary. (C) 2002 - ATI Technologies, Starnberg, GERMANY' taints kernel.

Unable to handle kernel NULL pointer dereference at virtual address 00000000

 printing eip:

e1fbb636

*pde = 00000000

       ___      ______

      0--,|    /OOOOOO\

     {_o  /  /OO plop OO\

       \__\_/OO oh dear OOO\s

          \OOOOOOOOOOOOOOOO/

           __XXX__   __XXX__

Oops: 0000 [#1]

PREEMPT

Modules linked in: fglrx

CPU:    0

EIP:    0060:[<e1fbb636>]    Tainted: P   VLI

EFLAGS: 00213246   (2.6.6-mm2)

EIP is at firegl_init+0x46/0x110 [fglrx]

eax: e1fe2200   ebx: 00000000   ecx: 00000002   edx: e1fe2220

esi: dcdb7000   edi: e1fe2250   ebp: c03bbaa0   esp: dcdb7f50

ds: 007b   es: 007b   ss: 0068

Process modprobe (pid: 6371, threadinfo=dcdb7000 task=dcbce110)

Stack: 0000000f 00000000 00000000 00000000 00203282 e1fe2200 e1fe2200 e1fe525e

       00000000 00000000 0000001a 00000019 0000001b e1faafc0 e1f99640 e1f99740

       0805a0c0 fffffffc c03bbab8 c03bbab8 e1fe1ea0 c012cb52 ffff0001 dcdb7000

Call Trace:

 [<e1fe525e>] firegl_init_module+0xee/0x184 [fglrx]

 [<c012cb52>] sys_init_module+0x102/0x210

 [<c0103e79>] sysenter_past_esp+0x52/0x71

 

Code: 00 fd e1 ba c1 79 fd e1 89 54 24 04 e8 f4 dd ff ff c7 04 24 0b 00 00 00 e8 38 db ff ff 89 c2 f7 da 8b 5c 24 18 89 d0 83 c4 1c c3 <81> 3b 00 00 02 10 74 22 c7 04 24 80 00 fd e1 b8 c1 79 fd e1 89
```

May ati and nvidia forever burn in hell for not opening up their drivers.

----------

## Wedge_

Anior: disable the "Use register arguments" option in the "Processor type and features" section of your kernel config and try it again.

----------

## Admiral LSD

*slaps forehead*

I should have realised that earlier, Register Arguments are permanent on -mm. You need to reverse this patch to put the option to disable them back in the config menus:

http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6/2.6.6-mm1/broken-out/force-config_regparm-to-y.patch

(yes it's for -mm1 but it should work on -mm2 and -mm3 as well otherwise just grab the version from the relevant dirs by changing the '2.6.6-mm1' above accordingly)

----------

## Anior

Ah, that would explain it.

I couldn't find it but I knew that I've seen that option before.

Will patch and test now.

----------

## Anior

Patch applied fine everything seems to work.

Great :-)

----------

## Wedge_

If you're interested, there are a couple of patches in this thread for 3.2.8 and 3.7.6 that I think will allow you to use the drivers with the register argument stuff enabled. I haven't tried them but they're there if anyone wants to give it a go.

----------

## misao

Works great for me here too (2.6.6-mm2, ati-drivers 3.7.6-r1)

Had to hack the kernel config to disable REGPARAM, but other than that went very cleanly.

-mis

----------

## Admiral LSD

If you use that patch I posted (you'll have to use the -R switch to reverse so patch -Rp1) then you don't have to hack the config, the option will be back on the config menus allowing you to enable/disable it from there. I'll defintely be checking out the patch that claims to make the drivers work with it enabled though as pretty soon it'll be the permanent kernel default (though why I don't really know, x86 doesn't really benefit from it I'm told. The only real reason I can think for forcing it on is that it breaks binary drivers) and we'll need a better way of dealing with it.

edit: Well, it works. I *can* get direct rendering (and therefore hardware 3D) with the ATi drivers with CONFIG_REGPARM enabled using the patch but sadly it still breaks bootsplash meaning that for now I have to keep it disabled. At least we now know that the ATi drivers won't be a problem when this mess reaches the "stable" tree.

----------

## madmango

Hey - if anyone would be willing to post or link to those patched c files, that'd be great. I can't get the patches to apply no matter what I do.

I'm getting malformed patch errors, because I'm using the 3.7.6 drivers. I had a peek at the code, and the line numbers differ greatly from what you have posted here.

Maybe I'll download the old drivers, unrpm it, take out the two c files, patch them, manually copy them to /var/tmp/portage/ati-drivers-3.7.6/work/ and try that. Heh.

----------

## madmango

Nevermind, I got it to work. Had to put this in the ebuild, though 

```
 cp ~/patchfile.patch /var/tmp/portage/ati-drivers*/work/lib/modules/build_mod

patch -p1 </var/tmp/portage/ati-drivers*/work/lib/modules/build_mod/patchfile.patch

```

Note the -p1. The hunk succeeded with a -7 line offset.

Thanks guys. Wedge is god.

----------

## Admiral LSD

Which patches are you using? I'm running 3.7.6 as well and Wedges patch applied perfectly with -p0 (after I realised copying and pasting from the forum, even with COD tags, buggered up the spacing of course).

The REGPARM patch needed -p1 but if you reverse the patch that forces it (which is probably the best idea as lots of things still break with it) then you don't need to add it. Seems to work fine either way though.

----------

## Raistlin

i'm running a vanilla 2.6.6 with the 3.7.6 drivers. everything seems to work fine.

anyways, dmesg reveals that error, if i complile the kernel with vesa-support and framebuffer console. (i don't compile any ati-drivers into the kernel, nor as a module): 

```
...

mtrr: 0xc0000000,0x8000000 overlaps existing 0xc0000000,0x1000000

[fglrx:firegl_addmap] *ERROR* mtrr allocation failed (-22) 
```

but back in X everything works smooth (glxgears etc.)

does anybody have a clue, where that message comes from? what additional   information do you need?

thanks  :Smile: 

cheers, raist.

----------

## Wedge_

I don't know if that error actually causes any problems, but there's a possible fix for them here: http://www.rage3d.com/board/showthread.php?threadid=33736241

----------

## Raistlin

thx, i'll check that out.

cheers, raist.

----------

## woZa

Could this be a problem with gentoo-dev-sources (2.6.5-r1) also. I have a similar problem compiling the ati drivers - see link

https://forums.gentoo.org/viewtopic.php?t=173658&highlight=

----------

## TheCoop

could someone please put the patch on the previous page on a server? I cant get it to patch with -p0 or -p1:

```
Calculating dependencies ...done!

>>> emerge (1 of 1) media-video/ati-drivers-3.7.6-r1 to /

>>> md5 src_uri ;-) fglrx-4.3.0-3.7.6.i386.rpm

 * X11 implementation is xorg-x11.

>>> Unpacking source...

>>> Unpacking fglrx-4.3.0-3.7.6.i386.rpm

 * Applying fglrx-2.6-vmalloc-vmaddr.patch...                             [ ok ]

 * Applying fglrx-2.6-get-page.patch...                                   [ ok ]

patching file agpgart_be.c

Hunk #1 succeeded at 4414 with fuzz 2 (offset 3012 lines).

Hunk #2 FAILED at 7425.

1 out of 2 hunks FAILED -- saving rejects to file agpgart_be.c.rej

patching file firegl_public.c

Hunk #1 FAILED at 2052.

1 out of 1 hunk FAILED -- saving rejects to file firegl_public.c.rej

>>> Source unpacked.

Caught signal 2
```

----------

## Wedge_

Give me 5 minutes.

Edit: clicky

----------

## TheCoop

it still borks out, even when using epatch. it is 3.7.6-r1 you're meant to patch isnt it?

```
***** fglrx-page-count.patch *****

==================================

PATCH COMMAND:  patch -p0 -g0 < /usr/portage/media-video/ati-drivers/files/fglrx

-page-count.patch

==================================

patching file agpgart_be.c

Hunk #1 succeeded at 4414 with fuzz 2 (offset 3012 lines).

Hunk #2 FAILED at 7425.

1 out of 2 hunks FAILED -- saving rejects to file agpgart_be.c.rej

patching file firegl_public.c

Hunk #1 FAILED at 2052.

1 out of 1 hunk FAILED -- saving rejects to file firegl_public.c.rej

==================================
```

----------

## Wedge_

I made the patch against 3.2.8, but it worked for 3.7.6 as well going by some of the earlier posts here. There's another version of it in this thread, you could try that instead. If nothing else works, re-diff it, the changes are pretty minor.

----------

## TheCoop

those patches dont work either, wtf is going on?

----------

## TheCoop

ah, its sorted. You only need to apply the middle patch (the one regarding lines 4xxx), the others arent applicable

----------

## Admiral LSD

It's a bit late now but I should have posted this here in this thread sooner. I made updated ebuilds for 3.7.6 that automatically apply the page->count patch:

http://www.admirallsd.dyndns.org/~ianweb/media-video.tar.bz2

I know they work since I emerged them several times without incident on my own system. I've revised them since then to include the CONFIG_REGPARM changes but haven't updated the tarball. If anyone wants them (I don't need it personally since I don't use regparm as it also breaks bootsplash) just drop me a line and I'll upload the updated ebuilds.

----------

## d0lby

Thanks man - this fixed mine....

Can we just rename all the filenames so we can use the 3.9 drivers? Or can you post another ebuild with the newer ones?

----------

## Gamezace

Edit: Nevermind - I just realized how old all this stuff was ::facepalms::Last edited by Gamezace on Sun Feb 06, 2005 8:38 pm; edited 1 time in total

----------

## Wedge_

Are you trying to patch a new version of the driver? If so, it probably won't work as the code has changed.

----------

