180.* graphical corruption and freezes system

[fakbill]

Of course it isn't!
The main problem is that nvidia cannot reproduce this bug so far...
If someone could provide us with a simple way to trigger this problem it would help a lot.

[rockman1981]

Originally Posted by fakbill

Of course it isn't!
The main problem is that nvidia cannot reproduce this bug so far...
If someone could provide us with a simple way to trigger this problem it would help a lot.

probably reproducing our machine configuration would be a good start point.
That's all i (we) can do: attach xorg configuration file and kernel.
(here there are mine)
Another info: my distro is a gentoo box, with the following C/CXXFLAGS:
-O2 -march=core2 -pipe -fomit-frame-pointer
(pretty much conservative, i'd say).

[raelelectric]

Same problem here, the 177 series worked fine. I can trigger the problem with the 180.* drivers by previewing an OpenGL screensaver (Euphoria). I switched back to the 177 drivers and everything works fine.



Hp DV6745us notebook, Turion X2 proc, 4GB ram, Nvidia GeForce Go 7150m.
Debian Sid (Sidux), Kernel 2.6.27-10 (32-bit), KDE 3.5.

[walmartshopper]

If it helps to reproduce the problem, here's my setup:

Intel P35 or P45 chipset (Abit IP35-Pro & Asus P5Q Pro, happens on both)
Q6600 CPU
4GB DDR2 800mhz in a 2x2GB dual channel config (OCZ Reaper HPC)
MSI 8800GT 512MB OC
Slackware 12.2 (kernel 2.6.27)

To reproduce:

Run any openGL app.

[diegoocampo]

The but is still present in 180.18.
I attach my .xsession-errors just after one of this corruptions. Maybe it helps!.

[Rudd-O]

OK guys, I think I have "how to reproduce" nailed.

Here's my rig:

- ASRock 945GCM-S
- one 2 GB memory module (memtest+ed OK)
- two hard disks
- 500W power supply
- 8800 GT 256 MB, aux power connected to two separate rails from the power supply
- Fedora 10 64bit
- kernel-2.6.27.7-134.fc10.x86_64
- 180.18 driver version
- card temperature usually 56°C, never goes above 67°C
- CPU temperature never goes above 53°C

Here's the deal:

- run Compiz
- run glxgears, make it a BIG window
- wait, or interact with your windows, trigger the water effect, animations, move and poke the **** out of your windows with wobbly windows plugin enabled, etcetera

After a while the display will start updating jerkily, the jerks will become linearly more frequent as seconds pass, and then it suddently will stop refreshing ("freeze") and it will also stop responding to your kb/mouse commands. This freeze will be for a couple of seconds. Then the display will update once more, then freeze again. If you are playing audio, the audio will stutter and repeat itself once, then play normally (no screen updates obviously) for a couple seconds, then stutter again.

This will continue until you switch VTs (when you will notice that compiz is consuming quite a bit of CPU, but X is PEGGED to 99%, and if you wait fifteen seconds, they will go down to normal levels). Once the CPU usage has normalized when you are in the text VT, the audio playback will also normalize itself. But If you at any point return to X, it will once again freeze.

The only way is to switch VT or remotely log in via SSH (such as with the Terminal.app on the iPhone) then kill compiz (and glxgears!), return to X and start twm or some other non-composited 1970's garbage.

And any compositor will cause this, kwin, xcompmgr, etcetera. But compiz just makes it more easily triggerable.

I have also experienced this while running UT99 through Wine using the UT OpenGL video driver. Game runs fine for half an hour or so, then freeze, and after a few seconds, game "segfaults" with an UT error dialog box.

When the problem presents itself, the NVRM: Xid dmesg message also present themselves.

What does not work:

pci=nommconf idle=poll maxcpus=1: no difference
GlyphCache=0: no difference (once the problem presented itself)

What fixes the issue temporarily:

A reboot. Just killing and restarting compiz after the problem is an invitation for, after a few seconds, getting another series of freezes.

What I suspect:

The card is leaking memory when using 3D (remember that windows are just planes with mapped textures on the card, the compositor does this to composite the windows in a scene graph), and as it becomes memory-exhausted, 3D apps stop working properly.

[Rudd-O]

I had a hard time reproducing the bug, so I ran Compiz and five different glxgears instances. BAM. Ten minutes, 30 seconds. They all, one by one, froze and finally Compiz froze too. I did this while keeping an atop window watching for memory consumption increase on the X server. Turns out my RAM hypothesis is wrong, the memory consumption of the X server hardly increases from its baseline, and it certainly does not grow 256 MB or even close to that.

So that's the recipe to reproduce: run Compiz on an 8800 GT and 180.18 driver, then launch N glxgears instances -- you do not even need to make them big. You will see, soon, an eager GUI lockup until you kill them all from a VT or SSH.

NVRMS:

NVRM: Xid (0003:00): 12, COCOD 00000004 beef5097 00008297 00001aac 00000000
NVRM: Xid (0003:00): 12, COCOD 00000004 beef5097 00008297 00001aac 00000000
NVRM: Xid (0003:00): 12, COCOD 00000004 beef5097 00008297 00001aac 00000000
NVRM: Xid (0003:00): 12, COCOD 00000004 beef5097 00008297 00001aac 00000000
NVRM: Xid (0003:00): 12, COCOD 00000004 beef5097 00008297 00001aac 00000000
NVRM: Xid (0003:00): 12, COCOD 00000004 beef5097 00008297 00001aac 00000000
NVRM: Xid (0003:00): 12, COCOD 00000004 beef5097 00008297 00001aac 00000000
NVRM: Xid (0003:00): 12, COCOD 00000004 beef5097 00008297 00001aac 00000000

[kernelOfTruth]

Rudd-O, the problem you're describing here (in your last post before mine) most likely isn't caused alone by nvidia-drivers - afaik I noticed this kind of behavior with the 17X.XX or even 169.XX drivers and the group scheduler activated in the kernel

this was caused for me by CFS / the kernel's scheduler and graphics drivers and/or i/o latency not playing nicely together

check if your kernel has group-scheduler and any of the nifty other stuff of the CFS scheduler enabled and disable them & re-compile the kernel and try if it still causes those problems for you

meanwhile I'm gonna try to reproduce this hardlock on my laptop (let it run for at least 15 minutes ...)

merry christmas to everyone

and let's cross our fingers that this "fixes" this problem

[kernelOfTruth]

it's running for 30 minutes now (average load 9.65) I've killed several of those glxgears to be able to write (no running 4 of them),

I haven't seen any of this Xid or whatever but:

[15837.132720] CPU0: Temperature/speed normal
[15837.132723] CPU1: Temperature/speed normal
[16163.163709] CPU0: Temperature/speed normal
[16163.163709] CPU1: Temperature/speed normal
[16426.061944] Machine check events logged

I guess it's safe to say it's somewhat stable ...

for those of you who run into those problems and have group scheduler enabled, give it a try:

* disable it and re-compile your kernel

good luck

[rockman1981]

For what i saw it's not even related to gl.. i tried even opening a bare KDE4 session with no GL applications and no composite manager, and yet it crashes without doing anything weird (iirc i was just adjusting some windows).
Next steps: i'm trying changing distro (ubuntu) to see if it helps,
next one will be disabling totally composite in Xorg.conf.
And no, i had no group scheduler enabled in my kernel

[kernelOfTruth]

oh man - and this on Christmas

I most likely also encountered this problem right now:

GNU/Gentoo ~amd64, gcc-4.3.2-r3 (hardened toolchain), with glibc-2.9
kernel 2.6.28-rc8-zen1
GUI: kde 4.2 beta2 (from svn)
hardware platform: dell xps m1330

estimated uptime until crash + hardlock (2-4 hours)

running apps / procedure leading to crash:
before crash 1) akregator (3.5), firefox 3.1 beta2, browsing forums w. flash, reading emails (gmail, web.de), updating system (emerge -e system) emerging via tmpfs (only finished compiled stuff is being replaced on disk), listening to music (vlc)

until crash 2) browsing forums, watching dvd (non-encrypted) via xine, switching through opened windows

near before crash 3) listening to music via vlc, browsing through forums

4) went away talking, leaving the computer on its own; most likely the screensaver wanted to kick in but didn't do; kwin and/or plasma(-workspace / desktop) crashed from what I could see (the window-decoration was gone and no window-switching anymore possible)
I switched back to VT1 and wanted to switch back but couldn't as it was hardlocked

it didn't react to magic sysrq key - I also saw no other (chanigng) output besides VT1, afaik numlock + caps lock were flashing

this didn't happen with gnome and compiz-fusion so far for me so I'll switch back gnome + compiz-fusion for some time

perhaps certain plugins / way of animations in kwin and/or compiz-fusion trigger this hardlock more early (e.g. wobbly windows)

as I don't have this enabled it could be ...

experiment with compiz-fusion and the plugins you're using if you use it and try to disable stuff you don't really need and see whether that temporarily fixes it

[rockman1981]

Could you check if in your xorg.conf the option "AddARGBGLXVisuals" is enabled?
And if so, try disabling it?
Maybe i'm wrong again, but it seems a bit more stable now..