Hello. After upgrading my kernel to 4.14 I noticed strange behavior: If I load X (KDE 3.5.10 session with built-in compositor [kompmgr], self-compiled with many patches, X server 1.19.5, nouveau DDX git) and start to use seamonkey 2.49 (again, self-compiled with gtk2 toolkit, not default gtk3) - after some hours of use X started to eat a lot of CPU time, new windows appear after delay, glxgears slow down to 11 fps or so from default 60. If I restart X session - everything back to normal, for few hours. If I quit seamonkey - CPU usage drops. But if I start it up again - CPU load returns quickly, and not go down until X restart.
Seamonkey use hw compositing (force-enabled) and multiprocess experimental option. Problem is, exactly same seamonkey with same set of tabs work fine on 4.12.0 kernel!
I set architecture to ia32, even if kernel compiled for x86_64 , because all my userspace is 32-bit.
01:00.0 0300: 10de:0606 (rev a2) (prog-if 00 [VGA controller])
01:00.0 VGA compatible controller: NVIDIA Corporation G92 [GeForce 8800 GS] (rev a2) (prog-if 00 [VGA controller])
X log, dmesg, opreport data will follow.
Created attachment 135703 [details]
Created attachment 135704 [details]
Created attachment 135705 [details]
Created attachment 135706 [details]
It seems setting option DRI to "2" instead of "3" workarounds this problem.
Bug still here on 4.14.9-x64.
But it seems if I use "xset dpms force standby" X also doesn't eat CPU anymore. If X enters such state by default after some time of user inactivity - it also don't eat CPU time. Unfortunately, I can't do anything useful wih seamonkey if my screen is off.
This bug still around for me with 4.15.0
-- GitLab Migration Automatic Message --
This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/385.