# More bizarre ATI whoes [SOLVED]

## EddieOfTheRocks

Precursor sys-specs:

 *Quote:*   

> Linux spica 2.6.22-gentoo-r2 x86_64 Mobile AMD Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux ATI Radeon Mobility 9700

 

So I did a deep update yesterday only to find that my ATI drivers no longer function. It seems to have something to do with the new 2.6.22 kernel. The driver compiles fine, but when I try to load it, I get the following message:

 *Quote:*   

> FATAL: Error inserting fglrx (/lib/modules/2.6.22-gentoo-r2/video/fglrx.ko): Unknown symbol in module, or unknown parameter (see dmesg)

 

I check the kernel logs to see what's up and see the following:

 *Quote:*   

> fglrx: Unknown symbol compat_alloc_user_space

 

I've searched all over these forums and google and can't seem to find anyone that has had a similar problem. I checked through the kernel tree to see if there is some section I am not compiling that contains a compat_alloc_user_space function but with no luck. I noticed a patch in the ati-drivers regarding ioctl that I thought might help so I tried to apply it but it did nothing. I have tried all ati-driver versions down to 8.35 with no luck.

Here is a weird kicker, when I enable mtrr in the kernel, the module loads. Of cource then the module fails in X because mtrr has to be disabled for ati-drivers to work with x86_64.

Any ideas. Can anyone tell me a little something about compat_alloc_user_space?

----------

## Nsane457

From /include/asm-x86_64/compat.h:

181 /*

182  * A pointer passed in from user mode. This should not

183  * be used for syscall parameters, just declare them

184  * as pointers because the syscall entry code will have

185  * appropriately comverted them already.

186  */

187 typedef u32             compat_uptr_t;

188 

189 static inline void __user *compat_ptr(compat_uptr_t uptr)

190 {

191         return (void __user *)(unsigned long)uptr;

192 }

193 

194 static inline compat_uptr_t ptr_to_compat(void __user *uptr)

195 {

196         return (u32)(unsigned long)uptr;

197 }

198 

199 static __inline__ void __user *compat_alloc_user_space(long len)

200 {

201         struct pt_regs *regs = task_pt_regs(current);

202         return (void __user *)regs->rsp - len; 

203 }

Often times if the kernel source is not entirely clean these kind of errors might happen.

It's a longshot but if you haven't tried it already it's worth a shot:

1. Copy your kernel config to a safe place.

2. In a terminal "cd" into the kernel source directory.

3. Run "make mrproper".

4. Move the config into the kernel source directory as ".config".

5. Recompile the kernel.

----------

## EddieOfTheRocks

I tried cleaning the kernel tree with no luck. I even tried re-building my configuration from scratch (since I imported a 2.6.20 kernel config) and still the same issue. I'll just keep using my 2.6.20 kernel and wait for the next kernel release.

----------

## Crispy Beef

I am having the exact same problem since upgrading to kernel 2.6.22, I've been searching high and low for the answer.  I switched to a previous kernel (2.6.15) and it worked just fine so I can only assume that it's something in this latest version that is causing the issues.

Fow now I think I'm going to drop back to a previous working kernel version as the answer but there has to be a reason for this???

----------

## jmbsvicetto

Hi.

 *Crispy Beef wrote:*   

> Fow now I think I'm going to drop back to a previous working kernel version as the answer but there has to be a reason for this???

 

It's typical for proprietary drivers to have some problems with keeping up with kernel updates - ati is particulary know for that.

However, did you emerge ati-drivers after updating your kernel? What version of ati-drivers are you using?

----------

## Crispy Beef

 *jmbsvicetto wrote:*   

> Hi.
> 
> It's typical for proprietary drivers to have some problems with keeping up with kernel updates - ati is particulary know for that.
> 
> However, did you emerge ati-drivers after updating your kernel? What version of ati-drivers are you using?

 

I'm currently on 8.40.4 of the ati-drivers, however I've tried a previous few versions too just to be sure.  This current version is in ~amd64 and it did work for me before the kernel upgrade.  So it's either something in the kernel that I'm not doing or - as you say - the ATI drivers not playing ball and conflicting with something.

----------

## ohadbasan

Hello,

I also experience problems after upgrading from 2.6.20 to 2.6.22

same version of ati-drivers as yours

but i get a different error message

FATAL: Error inserting fglrx (/lib/modules/2.6.22-gentoo-r2/video/fglrx.ko): Operation not permitted

Odd...

----------

## Crispy Beef

I've now managed to get the combination working, but it wasn't exactly a quick solution.  I stripped out X and also Gnome entirely and then emerge'd them again, then ran revdep-rebuild -X to make sure there were no other issues.

The only issue I have now is my keyboard not working, but I think that's unrelated to this thread.  To strip out X and gnome I used the world file in /var/lib/portage and did the following:

```
$> emerge `cat /var/lib/portage/world | grep x11` -C

$> emerge `cat /var/lib/portage/world | grep xorg` -C

$> emerge `cat /var/lib/portage/world | grep gnome` -C

$> emerge xorg-x11 gnome

$> revdep-rebuild -X
```

Don't forget to put a 'p' after the -C (-Cp) option to check that you're only removing what you want to.  When you're happy only the packages you want removed are in the list ditch the p.

Maybe this was overkill but it's cured the problem on my system.  :Smile: 

It would seem that it wasn't a kernel problem after all as I haven't recompiled it since the problems I has having earlier. Not a clue what it was though, if anybody knows then would like to hear.

----------

## ohadbasan

cleaning by "make mrproper"

and building it again with my old .config file solved the problem for me.

----------

## EddieOfTheRocks

I know this thread is long since dead, but after all this time I have figured out the problem to be that the new drivers need MTRR enabled in the kernel. The old situation with AMD64+ATI was that it needed to be disabled.

----------

