95% CPU usage with driver 256.35 ?!!

[StringCheesian]

konst: What if the driver was changed to rely on glx more even for the 2D stuff you do use? You should at least try to reproduce the issue just once with the full drivers with glx.

[damentz]

Here is my output of GLX from Xorg.log

(II) LoadModule: "glx"
(II) Loading /usr/lib/xorg/modules/extensions/libglx.so
(II) Module glx: vendor="NVIDIA Corporation"
        compiled for 4.0.2, module version = 1.0.0
        Module class: X.Org Server Extension
(II) NVIDIA GLX Module  256.35  Wed Jun 16 19:10:31 PDT 2010
(II) Loading extension GLX

Here is yours:

[ 34784.830] (II) LoadModule: "glx"
[ 34784.830] (II) Loading /usr/lib64/xorg/modules/extensions/libglx.so
[ 34784.830] (II) Module glx: vendor="X.Org Foundation"
[ 34784.830]    compiled for 1.8.1.901, module version = 1.0.0
[ 34784.830]    ABI class: X.Org Server Extension, version 3.0
[ 34784.830] (==) AIGLX enabled
[ 34784.830] (II) Loading extension GLX

If you're going to tamper with a critical subsystem of the installation and refuse to load nvidia's glx module for debugging, then you're not giving us much to help you with. And, if you're that concerned with the closed source GLX module, why don't you just use nouveau? From what I understand, it's good enough for a 2d desktop and minor desktop effects (not even sure about that).

[konst]

Originally Posted by damentz

Here is my output of GLX from Xorg.log

(II) LoadModule: "glx"
(II) Loading /usr/lib/xorg/modules/extensions/libglx.so
(II) Module glx: vendor="NVIDIA Corporation"
        compiled for 4.0.2, module version = 1.0.0
        Module class: X.Org Server Extension
(II) NVIDIA GLX Module  256.35  Wed Jun 16 19:10:31 PDT 2010
(II) Loading extension GLX

Here is yours:

[ 34784.830] (II) LoadModule: "glx"
[ 34784.830] (II) Loading /usr/lib64/xorg/modules/extensions/libglx.so
[ 34784.830] (II) Module glx: vendor="X.Org Foundation"
[ 34784.830]    compiled for 1.8.1.901, module version = 1.0.0
[ 34784.830]    ABI class: X.Org Server Extension, version 3.0
[ 34784.830] (==) AIGLX enabled
[ 34784.830] (II) Loading extension GLX

If you're going to tamper with a critical subsystem of the installation and refuse to load nvidia's glx module for debugging, then you're not giving us much to help you with. And, if you're that concerned with the closed source GLX module, why don't you just use nouveau? From what I understand, it's good enough for a 2d desktop and minor desktop effects (not even sure about that).

My operating system, called Gentoo Linux, allows me to choose which glx module I want to use so it's a moot point whether or not the Nvidia glx module is loaded cause I choose not to use it.

nouveau is not ready yet for dual-link LCD screens. Anyway driver version 195.36.24 seems to work ok.

[mooninite]

Originally Posted by konst

nouveau is not ready yet for dual-link LCD screens. Anyway driver version 195.36.24 seems to work ok.

Must be /your/ screens. My Dual-Link DVI LCD screens work fine with nouveau.

[mdriftmeyer]

Originally Posted by konst

Like I said I don't use any opengl apps. The nv driver doesn't do video scaling so video look bad with it. The nouveau driver can't do duallink DVI well yet.

Your Desktop Environment uses OpenGL.

[konst]

Originally Posted by mdriftmeyer

Your Desktop Environment uses OpenGL.

I turned off all opengl effects.

[konst]

Originally Posted by mooninite

Must be /your/ screens. My Dual-Link DVI LCD screens work fine with nouveau.

Will try it with a new kernel.

[StringCheesian]

Originally Posted by konst

My operating system, called Gentoo Linux, allows me to choose which glx module I want to use so it's a moot point whether or not the Nvidia glx module is loaded cause I choose not to use it.

In an attempt to reproduce your problem, I:
1. ran `eselect opengl set xorg-x11`
2. restarted xorg
3. logged into KDE 4.4.4 (same version as you)
4. made sure compositing was disabled
5. verified that my /var/log/Xorg.0.log looks like yours
6. ran htop

CPU usage according to htop varied between 0% and 2.5% in both cores.

gentoo ~amd64 (not funtoo)
gentoo-sources 2.6.34-r1
nvidia-drivers 256.35
xorg-server 1.8.1.902 (you're running 1.8.1.901)
Athlon 64 X2 4600+ (2.4GHz, very similar to your CPU)
GeForce 9600GT

I still think your wacky configuration (nvidia driver without glx) is one of the roots of your problem, but it must not be the only cause.

[konst]

Originally Posted by StringCheesian

In an attempt to reproduce your problem, I:
1. ran `eselect opengl set xorg-x11`
2. restarted xorg
3. logged into KDE 4.4.4 (same version as you)
4. made sure compositing was disabled
5. verified that my /var/log/Xorg.0.log looks like yours
6. ran htop

CPU usage according to htop varied between 0% and 2.5% in both cores.

gentoo ~amd64 (not funtoo)
gentoo-sources 2.6.34-r1
nvidia-drivers 256.35
xorg-server 1.8.1.902 (you're running 1.8.1.901)
Athlon 64 X2 4600+ (2.4GHz, very similar to your CPU)
GeForce 9600GT

I still think your wacky configuration (nvidia driver without glx) is one of the roots of your problem, but it must not be the only cause.

Actually now I'm running xorg-server 1.8.1.902 and have a GeForce 8800GTX.

One big difference is that I use a hardened kernel ver 2.6.32 which doesn't allow the glx module to run code on the stack (which is the way I set it to not allow that).
Since the Nvidia driver is closed source, the open source community can't see if there are any other security risks so I don't use the glx module.

It could be the hardened kernel or that your using a newer kernel but that doesn't explain why Nvidia driver ver 195.36.24 seems to work ok.

Anyway I plan to start using the nouveau driver when it works with dual-link LCD monitors so I won't have to depend on Nvidia closed drivers.

[Mango87]

Originally Posted by konst

the open source community can't see if there are any other security risks

This sounds stupid even in itself.

so I won't have to depend on Nvidia closed drivers.

After this post Nvidia will of course release its driver's source code.

The problem here doesn't lie with the Nvidia driver. It lies between your monitor and the chair you are sitting in.

[konst]

Originally Posted by Mango87

This sounds stupid even in itself.


After this post Nvidia will of course release its driver's source code.

The problem here doesn't lie with the Nvidia driver. It lies between your monitor and the chair you are sitting in.

You are really ignorant. One more person to put on ignore. If you have nothing to contribute to the topic then you're wasting people's time.

[StringCheesian]

Originally Posted by konst

Since the Nvidia driver is closed source, the open source community can't see if there are any other security risks so I don't use the glx module.

Do you seriously believe that nvidia's glx is responsible for the majority of the security holes you're worried about, and that the rest of nvidia driver is relatively safe? If you have reason to believe that, then I guess using nvidia's driver without nvidia's glx could be rational. If you're merely guessing or hoping that is the case, then there is nothing rational about your configuration.

If you don't trust code that can't be inspected by the open source community, then it's silly to use nvidia's driver at all. Using nvidia's driver without its glx component still violates your own security principals.

If you're willing to make an exception for part of the nvidia driver, then you might as well make an exception for the entire driver including the glx part of it. That way you would enjoy fewer bugs with a better tested configuration.