Go Back   nV News Forums > Linux Support Forums > NVIDIA Linux

Newegg Daily Deals

Reply
 
Thread Tools
Old 06-03-11, 09:38 PM   #1
Eevee
Registered User
 
Join Date: Jun 2011
Posts: 2
Default Temporary X freezes when repainting under Compiz 0.8.6

After running under Compiz for a while, particular windows start to become "cursed", for lack of a better word. If I try to scroll a cursed window, X jumps to 100 cpu use and becomes completely unresponsive for several seconds as the window repaints. Sound continues to play without interruption, the mouse cursor either works fine or vanishes entirely, and the screen doesn't update at all during this period. Lately, cursed terminals (roxterm) have also triggered freezing whenever I type in them at all—even a single keystroke in a new shell.

If I tried to scroll with the mouse wheel, the problem is compounded; seemingly a consecutive soft freeze for every click of the wheel. Windows sometimes uncurse themselves after a while, or after some combination of minimizing, switching window managers, resizing, etc. Most cursed windows are new windows.

Cursed windows are always from the same few programs: generally Firefox, evince, terminals with translucent backgrounds, or OpenOffice.org. I don't know if this is because these programs are accelerated, or because they're just the most frequently used.

The problem never happens with metacity. I didn't have it with the nouveau driver, either, but that was unusable for different reasons. I've had the same issue for quite a while across various versions of the nvidia driver, dating back at least to the 19x series.

Recently, I've seen a very brief black flicker whenever a window becomes cursed. Running under -debuglevel 6, I notice that every such flicker is accompanied by "The NVIDIA X driver has encountered an error; attempting to recover..." and "Error recovery was successful." in the X log. I tried an strace during a freeze, and saw a large block of ioctl() calls to fds 9 and 11 (/dev/nvidiactl and /dev/nvidia0) followed by a longer and slower string of SIGALRM lasting about the duration of the freeze.

I've had some other scattered and intermittent issues; many of them have disappeared with driver updates. The ones I've seen recently are:
  • New terminals, after being maximized, are sometimes missing scrollbars; instead there's a transparent strip where it would be.
  • Windows that aren't quite cursed will sometimes turn partially black and have trouble recovering, even after a few resizes or minimizes. I've only seen this recently with Firefox 4; sometimes it's all black with a few toolbars and other native controls painted, sometimes the content area will be divided along a diagonal with the upper half black.
  • When the screen locks and I enter my password to unlock it, there's sometimes a noticeable delay between the dialog disappearing and the desktop reappearing. The screen just remains black in the meantime.

Unlike most of the problems I've found after many rounds of Googling, X very rarely freezes or crashes outright. It's happened after the cursing gets particularly bad, but only a handful of times in the past couple years.

Other observations:
The problem only starts happening after some time, but I suspect it's triggered by too much video card use, whatever that means. I've noticed that:
  • The problem starts happening much sooner after boot since switching to Firefox 4, which is accelerated, and which usually has quite a few tabs open.
  • Similarly, I can trigger the problem after boot by opening enough videos, glxgears, PDFs, terminals, etc.; but the mere presence of Firefox triggers it in other windows within minutes.
  • If I switch from metacity to compiz while Firefox is running, or launch Firefox under compiz, then Firefox hits 100 cpu and churns possibly indefinitely. Again, this only happens if I do either some time after boot; it launches just fine in a fresh GNOME session. strace just gave me a few hundred sched_yield() calls over the course of ~20s, and not much else activity.
  • Restarting compiz, or switching to metacity for a while then back to compiz, doesn't fix the problem once it's started.

Maximized windows are much more common targets; again, this could be because they use more GPU memory, or just because I have a lot of maximized windows.

3D applications run under metacity run just fine, but: I think once or twice X crashed after a particularly long session of Team Fortress 2. This was ages ago, though, and I haven't done much gaming since.

System:
Two identical 1680×1050 monitors under TwinView.
8800 GTS; 384 MB onboard RAM.
nvidia driver 270.41.06 obtained from the x-updates PPA.
Ubuntu 10.10. I started with 32-bit 8.04 and upgraded every release through 10.04, then installed clean with 64-bit 10.10 but kept all the dotfiles in my home directory.
X 1.9, GNOME 2.28.

I have tried:
Resetting Compiz to factory defaults. Disabling all Compiz plugins except absolute necessities like window decorations.

Fiddling with sync-to-vblank in both the nvidia driver and compiz. All combinations of indirect rendering and loose binding for compiz.

Enabling triple buffering; disabling powermizer (which my card doesn't actually have); enabling the backing store; disabling UseEvents; changing initial pixmap placement to 1; disabling the glyph cache.

Booting into a video memory stress test, which found no problems.


Not sure what else I can do about this. I've never found anyone with the same problem, and compiz runs happily on other machines in the house—one with a different nvidia card, one with integrated Intel. But besides compiz's erratic behavior, I can't find any evidence that this might be a hardware problem.

I'd rather not drop compiz entirely, as it does provide some useful functionality. It's just making my machine kinda useless as well.
Attached Files
File Type: gz nvidia-bug-report.log.gz (142.0 KB, 59 views)
Eevee is offline   Reply With Quote
Old 06-03-11, 10:42 PM   #2
Eevee
Registered User
 
Join Date: Jun 2011
Posts: 2
Default Re: Temporary X freezes when repainting under Compiz 0.8.6

Well that was interesting.

I just had a GIMP window of a (large) photo turn completely black, with only the marker in the rulers, the status bar, and the layer outline painting.
If I tried to scroll, I got the familiar accurséd X freeze, and only the new region of the image rendered; the rest stayed black.
Resizing the window below some threshold fixed both problems. Resizing it bigger again caused both to reappear, but only sometimes. Each "bad" resize was accompanied by the familiar flicker.

Screenshot attached, though it doesn't seem too helpful. The window I used to crop the screenshot had the same problem.
Attached Thumbnails
Click image for larger version

Name:	gimp-black.png
Views:	69
Size:	44.2 KB
ID:	42855  
Eevee is offline   Reply With Quote
Reply


Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 05:55 PM.


Powered by vBulletin® Version 3.7.1
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Copyright ©1998 - 2014, nV News.