# [solved, sort of] 2.6.26, MTRR, PAT & nvidia-drivers

## asturm

Ok, now since gentoo-sources-2.6.26 my system hardlocks if I'm trying to start anything 3D. Apart from that it is perfectly stable.

There's this new kernel option called 'x86 PAT support' which I enabled despite its subtle warning about possible video driver breakage. This is likely to be the case on my system, but I haven't tried it without PAT yet.

1.) Is that kernel option generally not compatible with nvidia-drivers or is there a solution?

2.) Do I have to change boot parameters for PAT to work?

```
kernel /boot/kernel-2.6.26-gentoo root=/dev/sda5 video=uvesafb:1900x1200-32,mtrr:3,redraw
```

EDIT: Ok, this is interesting. It seems x86 PAT is not the culprit here...

----------

## Hu

Do you also experience lockups when using the open source drivers for your card to render 3D?  Is there any output from the kernel indicating that a panic occurred?

----------

## d2_racing

Also, what Nvidia driver are you using ?

Did you try the ~x86 version ?

----------

## Monkeh

PAT works fine.

Does 2.6.26 require a patch for nvidia-drivers to build? I know git does (where it works fine).

----------

## asturm

 *Hu wrote:*   

> Do you also experience lockups when using the open source drivers for your card to render 3D?  Is there any output from the kernel indicating that a panic occurred?

 

I don't have the open source drivers available right now, but I don't see how those could be an option anyway. As for the lockup, the system freezes without further output. I could try to ssh the system though.

I'm always using the ~amd64 version of nvidia-drivers, nvidia-drivers-177.13 right now.

Unfortunately I don't have much time at the moment, I'm back at 2.6.25-r7 which does its job.

----------

## Hu

 *genstorm wrote:*   

> I don't have the open source drivers available right now, but I don't see how those could be an option anyway. As for the lockup, the system freezes without further output. I could try to ssh the system though.
> 
> I'm always using the ~amd64 version of nvidia-drivers, nvidia-drivers-177.13 right now.
> 
> Unfortunately I don't have much time at the moment, I'm back at 2.6.25-r7 which does its job.

 

Panic reports which are only reproducible when using tainted kernels generally do not get much attention upstream.  If you want them to look at the problem, you will need to reproduce the issue with the open source drivers.

Being logged in over ssh will not get you any extra information if the lockup is caused by a kernel panic.  You could try using a serial console, or switch to a text console and run the 3D application from there.

----------

## asturm

Ok, this is solved. I'm not exactly sure what it was though.

Things changed:

klibc-1.5.8 --> klibc-1.5.12-r1

gentoo-sources-2.6.26 --> -r1 (with the exact same .config)

Maybe I'll try 2.6.26 again.

@Hu: It's clear that I can't get much support with a tainted kernel. Bloody blob anyway, I hope I can soon get rid of it.  :Wink: 

----------

## Hu

 *genstorm wrote:*   

> Ok, this is solved. I'm not exactly sure what it was though.
> 
> Things changed:
> 
> klibc-1.5.8 --> klibc-1.5.12-r1
> ...

 

My guess would be on the jump from =sys-kernel/gentoo-sources-2.6.26 to =sys-kernel/gentoo-sources-2.6.26-r1.

I did not mean to imply that we refuse to help you, but only to point out that the nature of binary blobs makes it substantially harder to help you.  There are some people who will refuse to help you, and some of them are the ones most capable of solving your problem.

If we had the panic text, we could make a guess as to the most likely cause, which could narrow down what fixed the problem.

----------

