Xorg eating CPU after installation of nVidia driver

[dho]

After installing the nVidia driver for my GeForce MX440 (which seems to be working fine, I get the nVidia logo when gdm/X11 starts), Xorg seems to be eating all CPU resources on one of the two CPUs in the system. This is a standard dual 866MHz P3 PC with a gig of RAM running Solaris 10.

Any ideas what could be going on?

--Devon

[netllama]

Can you check your X log for errors?

[lblume]

Jumping on that thread:
I've had a similar problem, Xorg using all CPU, and killing it does not get the console back (the screen becomes garbled, and stays so till next reboot).
I'm using a patched Solaris 10, with the 7667 driver, on an Athlon XP box with an FX5700 GPU on AGP 4x

There was nothing in the log whatsoever (/var/log/Xorg.0.log or dmesg).

I trussed the Xorg process, and it showed a lot of SIGALRM coming up.
Here is the first, with some context:
pollsys(0x08046DF0, 9, 0x08047640, 0x00000000) = 1
read(18, "10\004\007\0\0\0 C o m p".., 4096) = 16
read(18, 0x0842E050, 4096) Err#11 EAGAIN
writev(18, 0x08047838, 1) = 32
Received signal #14, SIGALRM, in pollsys() [caught]
pollsys(0x08046DF0, 9, 0x08047640, 0x00000000) Err#4 EINTR
lwp_sigmask(SIG_SETMASK, 0x00002000, 0x00000000) = 0xFFBFFEFF [0x0000FFFF]
setitimer(ITIMER_REAL, 0x08046AF0, 0x00000000) = 0
setcontext(0x08046920)

There are a lot of those EAGAIN on read(), with some SIGALRM, and then, it goes in an infinite loop of those:

pollsys(0x08046DF0, 28, 0x08047640, 0x00000000) = 1
read(29, "14\006\0\b\0E002 '\0\0\0".., 4096) = 28
read(29, 0x086DE748, 4096) Err#11 EAGAIN
writev(29, 0x08047838, 1) = 84
pollsys(0x08046DF0, 28, 0x08047640, 0x00000000) = 1
read(29, " +\001\0", 4096) = 4
read(29, 0x086DE748, 4096) Err#11 EAGAIN
writev(29, 0x08047838, 1) = 32
Received signal #14, SIGALRM, in pollsys() [caught]
pollsys(0x08046DF0, 28, 0x08047640, 0x00000000) Err#4 EINTR
lwp_sigmask(SIG_SETMASK, 0x00002000, 0x00000000) = 0xFFBFFEFF [0x0000FFFF]
setitimer(ITIMER_REAL, 0x08046AF0, 0x00000000) = 0
setcontext(0x08046920)
pollsys(0x08046DF0, 28, 0x08047640, 0x00000000) = 2
setitimer(ITIMER_REAL, 0x08047640, 0x00000000) = 0
read(29, " 51804\0 q02A0018601A001".., 4096) = 4096
read(29, "01\0 I0101\0 H01 <\002\0".., 4084) = 4084
Received signal #14, SIGALRM [caught]
lwp_sigmask(SIG_SETMASK, 0x00002000, 0x00000000) = 0xFFBFFEFF [0x0000FFFF]
setcontext(0x08047140)
Received signal #14, SIGALRM [caught]
lwp_sigmask(SIG_SETMASK, 0x00002000, 0x00000000) = 0xFFBFFEFF [0x0000FFFF]
setcontext(0x08047140)
Received signal #14, SIGALRM [caught]
lwp_sigmask(SIG_SETMASK, 0x00002000, 0x00000000) = 0xFFBFFEFF [0x0000FFFF]
setcontext(0x08047140)
Received signal #14, SIGALRM [caught]

and so on...

John Martin hinted there is a known bug polling a resource that is being investigated, is that it?

Laurent

[johnmartin]

| and so on...
|
| John Martin hinted there is a known bug polling a resource that is being investigated, is that it?

Looks similar, although the one I'm currently investigating requires OpenGL
double buffer sync to be enabled. After it is enabled, all subsequent instances
of the Xorg server will consume a CPU from pollsys() wakeups until the system
is rebooted.

I've only had one report of Xorg consuming a CPU from pollsys() wakeups
without having to start an OpenGL app with synchronized buffer flips.
This was on a GeForce 4 MX 440, but I have not yet been able to reproduce
it on any of my systems.

[lblume]

Hmmm, I'm very puzzled by this problem. Now, it also happens with only the kernel driver loaded, with Xorg using the nv driver. On second thought, maybe I forgot to comment the "Load glx" line after putting nv back.

Everytime I try to get some meaningful info to pinpoint its source, its behaviour changes slightly. Maybe some influence of the patches added between my tries, or more likely, the phase of the moon and the current weather.

Oh well.

I'll wait till your fix is available and give it a try with crossed fingers.

Laurent

[slink]

Hi,

I am running Solaris10 64bit on a dual Opteron box (w2100z) with
a 6800GT.

I can reproduce this effect whenever __GL_SYNC_TO_VBLANK=1
is set, be it just for one GL application or for the whole Xorg server
and all spawed processes. Although some applications do not seem
to induce the problem, others do.

For me, this seems to happen both with version 7667 and 7676 of
the driver.

Cheers, Nils

[netllama]

This issue should be resolved in the next driver release (1.0-8xxx).

Thanks,
Lonni

[ezust]

I just upgraded to xorg 7, and I'm using a GeForce fx5500,

I have a fresh install of Linux 2.6.16.5-kanotix-2 #1 SMP PREEMPT Sat Apr 15 20:20:23 CEST 2006 i686 GNU/Linux

I'm using the debian packages,
nvidia-kernel-2.6.16.5-kanotix-2_1.0.8756-4+1_i386.deb
and nvidia-glx which I got from packages yesterday.

I can only run xorg for about 1 minute before it locks up on me, eating 95% of my cpu and preventing me from doing anything. It's very reproducible.

[evilghost]

Originally Posted by ezust

I just upgraded to xorg 7, and I'm using a GeForce fx5500,

I have a fresh install of Linux 2.6.16.5-kanotix-2 #1 SMP PREEMPT Sat Apr 15 20:20:23 CEST 2006 i686 GNU/Linux

I'm using the debian packages,
nvidia-kernel-2.6.16.5-kanotix-2_1.0.8756-4+1_i386.deb
and nvidia-glx which I got from packages yesterday.

I can only run xorg for about 1 minute before it locks up on me, eating 95% of my cpu and preventing me from doing anything. It's very reproducible.

You realize you posted this in the 'NVIDIA Solaris Forum', it's likely to get more eyes over at 'NVIDIA Linux Forum'.