This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 533620 - KDE Launcher causes desktop to freeze for ~10 seconds (NVIDIA proprietary driver)
KDE Launcher causes desktop to freeze for ~10 seconds (NVIDIA proprietary dri...
Product: Fedora
Classification: Fedora
Component: xorg-x11-server (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
: CommonBugs, Patch, Reopened
: 533805 537008 537584 538275 538344 538836 539768 540064 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2009-11-07 17:32 EST by Justin Newman
Modified: 2010-01-27 14:29 EST (History)
67 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 538836 539768 (view as bug list)
Last Closed: 2010-01-27 14:29:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
KDE Software Compilation 217570 None None None Never 25136 None None None Never

  None (edit)
Description Justin Newman 2009-11-07 17:32:52 EST
Description of problem: When clicking the KDE launcher the entire screen freezes for about 10 seconds.

Version-Release number of selected component (if applicable): kdebase-workspace-4.3.2-1.fc12.x86_64

How reproducible: Problem should exists with a default KDE install, as far as I know.

Additional info: The issue was not present in Fedora 11 before upgrading. Additionally, the "classic" launcher seems to work fine.
Comment 1 Kevin Kofler 2009-11-07 17:38:25 EST
What video driver?
Comment 2 Justin Newman 2009-11-07 17:46:39 EST
nvidia-190.42 (binary driver)

The problem also now seems to occur when I launch Konsole and at other odd moments. When i launch konsole from the console I get the following message:

"Undecodable sequence: \001b(hex)[?1034h"
Comment 3 Kevin Kofler 2009-11-07 18:11:40 EST
Must be the same issue discussed on the mailing list then. It's a nvidia driver issue, as switching to Nouveau reportedly fixes it. Please report this issue to NVidia, they're the only ones who can fix it.
Comment 4 Justin Newman 2009-11-07 20:00:07 EST
I did some additional testing and the "undecodable sequence" error persists across drivers. However, the freezing does not.

Also, the freezing disappears from Konsole if compositing is disabled, but the launcher freezing persists whether compositing is on or off.

Since no other driver supports 3D on my system, I would appreciate it if somebody could report on their experience with KDE in this area with another driver that support 3D and compositing before the bug is dismissed as a driver issue.
Comment 5 Rex Dieter 2009-11-07 23:45:55 EST
Seems not fedora-specific either,

xorg-1.7.1 + nvidia driver + kde = slow/badness.
Comment 6 Justin Newman 2009-11-07 23:59:29 EST
Hmm, there's this comment on that Arch bug report:

"Without the new fedora patch, it works OK.
WITH the fedora patch, huge lag on KDE4. It should be removed."

That is in reference to Xorg. Maybe this is actually an issue w/ a Fedora Xorg patch?
Comment 7 Rex Dieter 2009-11-08 00:23:34 EST
Too bad the arch report doesn't mention what fedora patch they're talking about.

Anyway, here includes a possible workaround,
Comment 8 Justin Newman 2009-11-08 00:26:40 EST
It sort of does:

"BUT - if I apply only the first part of the Patch - which is:
- pPixmap = (*pScreen->CreatePixmap) (pScreen, width, height, pDraw->depth, 0);
+ pPixmap = fbCreatePixmap (pScreen, width, height, pDraw->depth, 0);"

That may be enough to pinpoint the patch?
Comment 9 Justin Newman 2009-11-08 00:37:59 EST
Also, that workaround (Option "UseEvents") doesn't work for me as either "True" or "False".
Comment 10 Rex Dieter 2009-11-08 01:52:05 EST
That's part of

re-assigning for comment/triage from x maintainers.
Comment 11 Rex Dieter 2009-11-08 17:24:00 EST
fwiw, the origin of that patch seems to come from bug #533236
Comment 12 Richard Colley 2009-11-08 17:36:56 EST
no problems on my 32bit system.  all reported cases seem to be on 64bit systems.
Comment 13 Adam Williamson 2009-11-08 18:17:39 EST
xserver-1.7.1-window-pictures.patch is the only patch Arch took (I checked their RCS).

Dave Airlie is aware of this, he has forwarded the patch to NVIDIA so they can fix their driver. The patch doesn't do anything wrong, slowness indicates the NVIDIA driver is doing something bad (wouldn't be the first time).

If anyone can reproduce this with a *clean* Fedora 12 config using nouveau _not NVIDIA_, that would be a much higher priority issue.

I have a scratch build of xorg-x11-server which is exactly the same as -7 but drops the patch in question up here:

anyone who really needs to use F12+KDE+NVIDIA can go with that X server build for now. I'll document this on CommonBugs before release.

Fedora Bugzappers volunteer triage team
Comment 14 Justin Newman 2009-11-08 19:40:50 EST
I can confirm that the above package fixes the problem for me. Good stuff!
Comment 15 Matěj Cepl 2009-11-09 06:07:02 EST
Thank you for letting us know.
Comment 16 Rex Dieter 2009-11-09 08:40:08 EST
*** Bug 533805 has been marked as a duplicate of this bug. ***
Comment 17 Adam Williamson 2009-11-09 12:09:09 EST
matej: um. 'the above package' doesn't correspond to 'CLOSED RAWHIDE' because it's just a scratch build for NVIDIA users to work around this problem, it's never going to go into a repo anywhere. We could close this as CANTFIX since it's a bug in NVIDIA proprietary driver, but not RAWHIDE.

Fedora Bugzappers volunteer triage team
Comment 18 Kevin Kofler 2009-11-09 14:21:41 EST
Reopening as it's clearly not fixed in Rawhide. I'd go for CANTFIX.
Comment 19 Mark van Rossum 2009-11-09 20:29:21 EST
But with the updated rpms, 
ghostview and gwenview now bring down X on my system!

Can someone else check as well?

NVIDIA 190.42, FX570M, i686

(uninformative) Backtrace:
0: /usr/bin/Xorg (xorg_backtrace+0x3c) [0x80e587c]
1: /usr/bin/Xorg (0x8048000+0x5eb66) [0x80a6b66]
2: (vdso) (__kernel_rt_sigreturn+0x0) [0x78240c]
3: /usr/lib/xorg/modules/drivers/ (0x101a000+0x964d5) [0x10b04d5]
Segmentation fault at address 0xa8416248

Fatal server error:
Caught signal 11 (Segmentation fault). Server aborting
Comment 20 Mark van Rossum 2009-11-09 20:32:21 EST
(In reply to comment #12)
> no problems on my 32bit system.  all reported cases seem to be on 64bit
> systems.  

My 32bit does show the bug....
Comment 21 Justin Newman 2009-11-09 23:10:33 EST
No problems with gwenview here. I just opened it and looked at a few pictures.
Comment 22 Mark van Rossum 2009-11-10 06:30:18 EST
(In reply to comment #19)
> But with the updated rpms, 
> ghostview and gwenview now bring down X on my system!
> Can someone else check as well?
> NVIDIA 190.42, FX570M, i686
> (uninformative) Backtrace:
> 0: /usr/bin/Xorg (xorg_backtrace+0x3c) [0x80e587c]
> 1: /usr/bin/Xorg (0x8048000+0x5eb66) [0x80a6b66]
> 2: (vdso) (__kernel_rt_sigreturn+0x0) [0x78240c]
> 3: /usr/lib/xorg/modules/drivers/ (0x101a000+0x964d5) [0x10b04d5]
> Segmentation fault at address 0xa8416248
> Fatal server error:
> Caught signal 11 (Segmentation fault). Server aborting  

TO be more precise: only happens when trying to view postscript.h
Comment 23 Adam Williamson 2009-11-10 11:10:43 EST
It's not too helpful to discuss issues in the proprietary driver here, as we're not going to fix it. :) The best place would probably be the Linux forum at, which is a sort-of semi-official NVIDIA driver support forum, NVIDIA employees monitor it.

Fedora Bugzappers volunteer triage team
Comment 24 James Laska 2009-11-11 15:01:05 EST
Tagging for addition to the CommonBugs page
Comment 25 Rex Dieter 2009-11-12 10:55:32 EST
*** Bug 537008 has been marked as a duplicate of this bug. ***
Comment 26 Roderick Johnstone 2009-11-16 07:15:59 EST
Sorry, but I can't see how to get the rpms referred to in #13. Can someone tell me please?
Comment 27 Mary Ellen Foster 2009-11-16 10:22:50 EST
I'm also seeing similar symptoms on an Acer TravelMate 8100 laptop with an ATI X700 radeon mobility graphics card (using the free "radeon" driver), but seemingly only when a second monitor is plugged in. So it might not be just an nVidia problem ...
Comment 28 Kevin Kofler 2009-11-16 12:28:42 EST
Scratch builds are automatically deleted after a week or two. The build output needs to be uploaded somewhere else if it should be permanent (and if nobody saved it, another scratch build has to be submitted first).
Comment 29 Roderick Johnstone 2009-11-16 15:49:36 EST
Kevin: Thanks for the explanation

Adam: Can you resubmit the build please or let me know where a copy was saved?
Comment 30 Adam Williamson 2009-11-16 21:14:24 EST
will do in a bit.

Fedora Bugzappers volunteer triage team
Comment 31 Adam Williamson 2009-11-16 21:15:18 EST
mary, that's almost certainly an entirely different problem. please file a new bug if you can provide a concrete reproduction scenario.

Fedora Bugzappers volunteer triage team
Comment 32 Rex Dieter 2009-11-17 14:54:13 EST
Here's a fresh scratch build like in comment #13 (which got garbage collected).

when it's done, I'll put it up in a repo somewhere for posterity.
Comment 33 Roderick Johnstone 2009-11-17 15:28:45 EST
Thanks Rex.
Comment 34 Rex Dieter 2009-11-17 15:31:14 EST
OK, as threatened,
Comment 35 Kevin Kofler 2009-11-18 03:30:56 EST
*** Bug 538275 has been marked as a duplicate of this bug. ***
Comment 36 Mary Ellen Foster 2009-11-18 04:48:34 EST
For future reference, here's the contents of my /etc/yum.repos.d/rdieter.repo -- I created this file, did a "yum update", restarted X, and now menus are opening as expected. Thanks, Rex! :)

name=xorg-x11-server rebuilds for nvidia users
Comment 37 Mary Ellen Foster 2009-11-18 05:20:12 EST
(In reply to comment #31)
> mary, that's almost certainly an entirely different problem. please file a new
> bug if you can provide a concrete reproduction scenario.

["that" is the same symptoms on a laptop using the free ATI drivers, but only in dual-head mode]

No, actually, I think it is another manifestation of the same problem. At least, installing rdieter's Xorg packages on the laptop in question also fixed the issue there too.
Comment 38 Ben Boeckel 2009-11-18 09:26:03 EST
*** Bug 538344 has been marked as a duplicate of this bug. ***
Comment 39 Stefan Neufeind 2009-11-18 13:28:23 EST
Rex, your packages also solved that problem for me. But it's been mentioned the bugfix itself is okay that's only a preliminary solution until nvidia fixes their driver it seems :-(
Comment 40 Adam Williamson 2009-11-18 18:37:38 EST
Mary, no, it really isn't. The bug here is that NVIDIA's proprietary driver does not work properly with a patch added to our X server package. It sounds like the driver you're running, on the system you're using, also has problems with the patch in question - but that STILL means it's a separate bug.

Please file it separately, against the radeon driver.

Fedora Bugzappers volunteer triage team
Comment 41 Adam Williamson 2009-11-18 18:55:29 EST
stefan, yes, this is a workaround not a fix. we can't ship the package with the disabled patch to everyone, as the patch is valid and fixes other problems.

Fedora Bugzappers volunteer triage team
Comment 42 Rex Dieter 2009-11-19 10:15:47 EST
(filed by nvidia,) documenting xorg upstream bug,
Comment 43 Jaroslav Franek 2009-11-20 14:14:09 EST
Sorry to spam closed bug, but I have kinda reproduced it on fresh installation of Fedora 12 with nouveau driver (having nvidia GT130 card with 768MB memory):

[franekj@localhost ~]$ uname -a
Linux localhost.localdomain #1 SMP Mon Nov 16 20:38:45 EST 2009 x86_64 x86_64 x86_64 GNU/Linux

[franekj@localhost ~]$ lsmod | grep nouveau
nouveau               544292  1
ttm                    41952  1 nouveau
drm_kms_helper         25376  1 nouveau
drm                   171296  4 nouveau,ttm,drm_kms_helper
i2c_algo_bit            6020  1 nouveau
i2c_core               28608  4 i2c_i801,nouveau,drm,i2c_algo_bit

When I e.g. click the (F) icon on the main panel, the desktop gets frozen for 4-5 seconds until the start menu appears.

Previously on Fedora 11 it was working without any such delay using nouveau as well. Now with Fedora 12, many operations regarding the KDE main panel exhibit the long waits (start menu, plazma button + settings bar, callendar, ...). On the other hand, the plazma button at the right-upper corner of the desktop works instantaneously.
Comment 44 Adam Williamson 2009-11-20 16:29:16 EST
are you sure this is a clean installation? it's not an upgrade that has bits of the proprietary driver (e.g. NVIDIA's libgl stuff) lying around?

Fedora Bugzappers volunteer triage team
Comment 45 Jaroslav Franek 2009-11-20 16:43:49 EST
Yes, very sure. I sacrificed Fedora 11 installation to perform a clean Fedora 12 installation, NO upgrade, the disk was reformatted. And definitely there never was proprietary nvidia driver installed, neither in Fedora 11, neither in Fedora 12.
Comment 46 Pete Havens 2009-11-21 17:48:05 EST
I also encountered this problem. I just installed the KDE 4.3.2 version of fedora 12 today along with the nVidia video drivers from rpmfusion. Things mostly worked, but upon clicking on the Kickoff button in the lower left corner, or upon opening the Krunner dialog with alt+f2, my laptop would hang for 40+ seconds (although I could move the mouse pointer, I couldn't do anything else). I installed the RPMs from rdieter's temporary repo listed above, and that seems to have fixed the problem for me. Here are my specs:

HP Pavilion Entertainment PC (dv7)

uname -a
Linux vizzini #1 SMP Sat Nov 7 21:41:45 EST 2009 i686 i686 i386 GNU/Linux

dmesg | grep -i 'nvidia.*kernel module'
NVRM: loading NVIDIA UNIX x86 Kernel Module  190.42  Tue Oct 20 20:18:32 PDT 2009

lspci | grep -i vga
01:00.0 VGA compatible controller: nVidia Corporation GeForce 9600M GT (rev a1)

Hope that helps,
Comment 47 Stephen 2009-11-21 19:22:14 EST
I followed the instructions in comment #36
(I'm using nvidia's 190.42 driver) and I wanted
to note that people using these patched files
_should_ rebuild their nvidia driver after installation
and reboot.

Without the rebuild (even after a reboot) it performed
_very_ oddly (everything was painted blackisk) -- so the driver
rebuild is important (along with the reboot).

I have Desktop effects running (with much of the eye
candy enabled) and it's working well (NO hangs or
slow downs with the panel).

Thank you Rex!
Comment 48 Aaron Plattner 2009-11-22 18:36:21 EST
I'm not sure why this bug is still CLOSED CANTFIX.  I posted a patch to fix the performance regression to the xorg-devel mailing list:
Comment 49 Rex Dieter 2009-11-22 20:29:34 EST
See also (cloned) bug #539768 , tracking the generally good feedback of testing the aforementioned patch ( from comment #48 ).
Comment 50 Adam Williamson 2009-11-23 14:53:31 EST
Can you please test this scratch build:

and see if that resolves the issue? Thanks.

To recap, for clarity (posting this to all three bugs): we have three bugs for this issue at present, as they manifested with different drivers and hardware.

Bug #533620 is the initial bug, considered to refer to using the NVIDIA proprietary driver. Bug #538836 is for a case affecting users of the 'radeon' driver for ATI/AMD cards in a dual-head configuration. And Bug #539768 is for a case affecting the free 'nouveau' driver for NVIDIA hardware with kernel modesetting disabled.

If the proposed scratch build appears to fix all three types, I'll re-combine them into bug 533620, as it would then be considered a bug in the X server addressed by the proposed patch in the scratch build (from NVIDIA).


Fedora Bugzappers volunteer triage team
Comment 51 Nickolay Bunev 2009-11-24 04:55:08 EST
=I can confirm that the rpms from the scrath build seems to solved the issue for me (NVIDIA proprietary 190.42-2).
Comment 52 Nickolay Bunev 2009-11-24 04:55:42 EST
I can confirm that the rpms from the scrath build seems to solved the issue for me (NVIDIA proprietary 190.42-2).
Comment 53 Stefan Neufeind 2009-11-24 05:01:33 EST
I can confirm as well that it works fine for me.
And it turns out the original window-patch by Fedora/RedHat that caused the problem fixes other crash-problems I experienced during the last days. That scratch-build now has the fix *and* doesn't hang withe the nvidia-driver ... nice.

Could you maybe push it to updates-testing?
Comment 54 Adam Williamson 2009-11-24 10:44:28 EST
*** Bug 539768 has been marked as a duplicate of this bug. ***
Comment 55 Adam Williamson 2009-11-24 10:45:56 EST
the initial reporter of the 539768 offshoot confirmed the scratch build helps that case, and one commenter from 538836 says it helps that case too; I'd support sending it to updates-testing now...

Fedora Bugzappers volunteer triage team
Comment 56 Adam Williamson 2009-11-24 14:59:02 EST
couple of reports from the forums that the scratch build works well too (with proprietary driver).

Fedora Bugzappers volunteer triage team
Comment 57 dominique 2009-11-24 15:07:40 EST
I test the latest version of x-server (1.7.1-7.fc12.2.rex.x86_64) and that work for me.
And now I have no x-crash when I work with gimp...
Good job.
Comment 58 Serge Droz 2009-11-25 15:27:12 EST
The koji build works fine here:
nVidia Corporation G71 [GeForce 7900 GS] (rev a1)
NVidia Driver 190.42
OS: Linux-x86_64

So far no side effects
Comment 59 Mark Bidewell 2009-11-25 15:30:19 EST
While the Koji build resolve most of the slowness, I have noticed that shutdown
and restart dialogs are slower to come up with UMS than KMS.

This is with the nouveau driver.  I am waiting until RPM Fusion ships the Nvidia driver to test that.
Comment 60 Stefan Neufeind 2009-11-25 16:00:45 EST
RPM Fusion already ships the nvidia-driver for F12 under updates-testing. And that works fine for me with the latest xorg-fixes mentioned in this thread.
Comment 61 Mark Bidewell 2009-11-25 16:59:51 EST
RPM fusion updates-testing driver works great!  BTW if we have the koji xorg builds install will the upgrade cleanly to the fixed versions from updates?
Comment 62 Orcan Ogetbil 2009-11-25 21:00:35 EST
I came a little late to the party but I wanted to report that Rex' packages in comment #34 fixed the freeze issue for me.
Comment 63 Adam Williamson 2009-11-25 21:24:17 EST
61: not at present, no, not until this fix (or a different one) gets pulled into actual Fedora CVS. for now it's an out-of-tree scratch build.

Fedora Bugzappers volunteer triage team
Comment 64 Eike Hein 2009-11-26 04:19:47 EST
There's a xorg-x11-server-Xorg-1.7.1-9 now which reintroduces the problem, coming from Rex' unofficial modified -7 build. I guess we need a new one for -9 now.
Comment 65 Adam Williamson 2009-11-26 12:45:41 EST
Can you try 1.7.1-12?

Fedora Bugzappers volunteer triage team
Comment 66 Eike Hein 2009-11-26 12:59:57 EST
Yep, -12 fixes the problem here.
Comment 67 Sergei LITVINENKO 2009-11-27 01:37:50 EST
Simple patch, based on , over official version of xorg-x11-server packet, fix my problem.
Comment 68 Eike Hein 2009-11-27 05:21:07 EST
Going by the changelog, that patch is also part of the -12 package on Koji.
Comment 69 Matěj Cepl 2009-11-27 12:09:05 EST
It's a long time since reporter said anything here. Could you please retest with packages from, please?

Anybody else, is there anybody who can reproduce THIS issue with the above linked package?

Thank you
Comment 70 Eike Hein 2009-11-27 12:18:23 EST
The -12 packages resolve the issue described in the initial report, yes. That's pretty much what everyone has been talking about in here.
Comment 71 dominique 2009-11-27 12:29:25 EST
I install the -12 packages and I have no X-crash when I work with Gimp.
For me it's good...
Comment 72 Sergei LITVINENKO 2009-11-27 12:55:01 EST
>> Can you try 1.7.1-12?

Yes, with xorg-x11-server version 1.7.1-12 from , KDE work as expected

Thanks a lot.
Comment 73 Adam Williamson 2009-11-27 13:11:32 EST
*** Bug 537584 has been marked as a duplicate of this bug. ***
Comment 74 Adam Williamson 2009-11-27 13:12:19 EST
*** Bug 538836 has been marked as a duplicate of this bug. ***
Comment 75 Adam Williamson 2009-11-27 13:14:11 EST
OK, I've merged the two offshoots of this bug that I asked to be split off back into this one, as it seems clear all the issues stem from this X server bug.

We now have multiple confirmations that -12 fixes the problems here.

Fedora Bugzappers volunteer triage team
Comment 76 Serge Droz 2009-11-27 13:40:04 EST
I can confirm, that 1.7.1-12 works just fine here.

Thanks & Cheers
Comment 77 nucleo 2009-11-27 15:16:51 EST
xorg-x11-server-1.7.1-12.fc12 works without delay in Kickoff.
But I have some problems in vmware with 1.7.1-12.fc12.
When virtual machine  starting:

A language-specific mapping from X keysyms to machine scancodes will be used, based on the detected keyboard type of "us101", because you are not using an XFree86 server running on the local machine.
However, this program's language-specific mapping may not be correct for your keyboard in all the details, because X keyboard mappings vary.
You can override specific key mappings in the virtual-machine configuration.

When switching virtual machine to full screen mode:

Unable to find an appropriate host video mode.
Adding the guest mode to the 'display' subsection of the 'screen' section of your /etc/X11/XF86Config or /etc/X11/xorg.conf and restarting X is likely to help.
Failed to switch to full screen SVGA mode.

xorg-x11-server-1.7.1-7.fc12.2.rex don't have problems with vmware.
Comment 78 Eike Hein 2009-11-27 16:00:45 EST
It appears that nVidia's patch is included in the newly-released xorg-server 1.7.2, btw.
Comment 79 Orcan Ogetbil 2009-11-27 17:23:02 EST
The -12 build from koji works :). I was going to give it a +1 but I don't see it in the bodhi. Is it safe to use it?
Comment 80 Adam Williamson 2009-11-27 18:16:26 EST
yeah, it's safe. don't worry about that tail you're growing, it's COMPLETELY normal. =)

I think the X guys are just rolling up a bunch of fixes before submitting a test update, at present.

Fedora Bugzappers volunteer triage team
Comment 81 Justin Newman 2009-11-30 12:58:55 EST
1.7.1-12 works for me (original bug reporter) as well, perhaps even faster than before. :)
Comment 82 Doran Barton 2009-12-02 00:52:15 EST
The -12 packages fix the problem for me as well. I'm running a Dell Latitude D830(N) w/ nVidia Corporation Quadro NVS 140M and Fedora 12 x86_64.
Comment 83 Don Harden 2009-12-02 07:41:27 EST
xorg-x11-server-Xorg-1.7.1-12.fc12.x86_64.rpm with 
xorg-x11-server-common-1.7.1-12.fc12.x86_64  fixed the problem for me on an HP dv7t1000 with a nVidia Corporation GeForce 9600M GT (rev a1).   

I don't run VMware on this laptop, but Virtualbox runs XP just fine with 1.7.1-12.

Thanks !!
Comment 84 Sergei LITVINENKO 2009-12-02 13:33:20 EST
>> but Virtualbox runs XP just fine with 1.7.1-12.

qemu-kvm runs Fedora-12 and CentOS-5.4 fine with 1.7.1-12 on GeForce 8800 GTX.

Comment 85 Mitchell Richters 2009-12-02 16:16:03 EST
1.7.1-12 works perfectly.

I also run VMware 7 on my laptop and do not have the fullscreen issue described earlier, though I do get a keyboard error which hasn't affected anything for me so far.

I'm running x86_64 FC12 and VMware x86_64 fyi...

Cheers to the bugfixers :)
Comment 86 Mikkel Lauritsen 2009-12-03 15:07:11 EST
FWIW the 1.7.1-12 build also improves the performance in other cases.

Since upgrading to F12 on a Lenovo T61P (using the nouveau driver on an nVidia Quadro FX 570M) the UI performance of a Java application running under the Sun 1.6.0_11 x64 JDK has been abysmal. More specifically it's the IntelliJ IDE, where basic things like moving the caret around in an editor was glacially slow.

After updating xorg to 1.7.1-12 this has improved enough to make it semi-usable, even though it's nowhere near the performance I have experienced on previous Fedora releases. In return suspend and resume works very well :-)

I'm using Gnome, and so far I haven't experienced any problems with other applications; it has only been IntelliJ which has suffered.
Comment 87 Matěj Cepl 2009-12-03 18:00:56 EST
OK, marking this bug as MODIFIED, and can I ask Mikkel or nucleo (either of them and let us know here the number of the bug, so other may join the party) to file a separate bug against xorg-x11-server component, please? Please, don't forget to attach your X server config file (/etc/X11/xorg.conf, if available), output of the dmesg command, and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below.

Thanks in advance.
Comment 88 Sergei LITVINENKO 2009-12-04 01:41:04 EST
On "Intel Corporation Mobile 945GME Express Integrated Graphics Controller (rev 03)" 1.7.1-12 work perfect too....

PS: Sorry, but I do not understand why it is not in updates yet? How long we have to wait? Is it not enough stable? Are there problems? Where? Who have problems?

There is documented problem in Fedora-12, there is solution, why is not commited?
Comment 89 Mikkel Lauritsen 2009-12-04 02:51:57 EST
Thanks, I have created bug 544203.
Comment 90 nucleo 2009-12-04 05:04:58 EST
I have created bug 544230
Comment 91 Vedran Miletić 2009-12-05 05:24:01 EST
*** Bug 540064 has been marked as a duplicate of this bug. ***
Comment 92 Raman Gupta 2009-12-10 02:15:11 EST
I also encountered the same issue with an nVidia GeForce 8800 GTS on F12 x86_64. The xorg 1.7.3-1 update in koji [1] also fixes the problem.

Comment 93 Martin Airs 2009-12-10 13:08:36 EST
I don't know if anyone is still interested, but on the f12 common bugs page it says to test and report to here

well, I've upgraded my xorg-x11-server-Xorg and xorg-x11-server-common to the new versions

and I can report that it fixes things for me :)

KDE loads up lighting quick, very happy
Comment 94 dominique 2009-12-10 14:52:32 EST
I also test the new version of xorg (1.7.3-1) and I note no regression since 1.7.1-12 version.
I have no crash when I work Gimp.
Comment 95 Riku Seppala 2009-12-13 04:25:59 EST
Please commit the fix to updates or updates-testing. Or at least fix Koji! :]

btw, nvidia 190.53 (prerelease) for Linux x86/x86_64 released.
Comment 96 Sergei LITVINENKO 2009-12-13 04:54:18 EST
>> Please commit the fix to updates or updates-testing. Or at least fix Koji! :]

Comment 97 Artem S. Tashkinov 2009-12-13 05:52:14 EST
(In reply to comment #95)
> Please commit the fix to updates or updates-testing. Or at least fix Koji! :]
> btw, nvidia 190.53 (prerelease) for Linux x86/x86_64 released.

NVIDIA driver cannot solve this problem.
Comment 98 Riku Seppala 2009-12-13 06:07:09 EST
(In reply to comment #97)
> (In reply to comment #95)
> > Please commit the fix to updates or updates-testing. Or at least fix Koji! :]
> > 
> > btw, nvidia 190.53 (prerelease) for Linux x86/x86_64 released.
> >  
> NVIDIA driver cannot solve this problem.  

"Disabled the UseEvents option for GeForce 8 series and higher GPUs due to a problem that causes occasional short hangs. It will be re-enabled when that bug has been tracked down and fixed."

I just noticed why koji is down...
Comment 99 Artem S. Tashkinov 2009-12-13 07:04:59 EST
(In reply to comment #98)
> "Disabled the UseEvents option for GeForce 8 series and higher GPUs due to a
> problem that causes occasional short hangs. It will be re-enabled when that bug
> has been tracked down and fixed."
> I just noticed why koji is down...

UseEvents options is NOT enabled here but I do have this issue.

From docs:

Option "UseEvents" "boolean"

    Enables the use of system events in some cases when the X driver is
    waiting for the hardware. The X driver can briefly spin through a tight
    loop when waiting for the hardware. With this option the X driver instead
    sets an event handler and waits for the hardware through the 'poll()'
    system call. Default: the use of the events is *disabled*.

// Emphasis is mine.
Comment 100 Kevin Kofler 2009-12-13 07:18:46 EST
That UseEvents issue has absolutely nothing to do with this bug.
Comment 101 Paulo Penteado 2009-12-14 15:45:34 EST
This is just to report my results:

The issue was fixed, though not yet with Compiz enabled, when I installed xorg-x11-server-1.7.1-12.fc12. The driver is xorg-x11-drv-nvidia-190.42-5.fc12.x86_64 from rpmfusion, on a kernel. The card is a GeForce GTX 260.

So for now I am using it with Compiz disabled, apparently with no problems. Switching to the nouveau driver is not an option for me, because I use CUDA.
Comment 102 Gilboa Davara 2009-12-14 18:00:08 EST
xorg-x11-server-*-1.7.3-1.fc12.x86_64.rpm from koji seems to solve this problem.
While KDE is somewhat slower than it's F11 counter-part, it's not longer a major issue.

- Gilboa
Comment 103 Michael Bunzel 2009-12-15 04:43:27 EST
I too can confirm that the -12 koji build successfully fixes the bug.

Issue: 2-7 second X freeze when displaying various KDE UI elements (krunner, calendar, panel config, etc)
Environment: F12 i686, KDE, nvidia driver. Not reproducible with nouveau driver
Comment: No side effects or slow down. Compiz works perfectly.
Comment 104 Darryl L. Pierce 2009-12-15 16:23:50 EST

This works for me as well on my desktop system with nVidia drivers from rpmfusion:

(mcpierce@mcpierce-desktop:~)$ rpm -qa *nvidia*
Comment 105 Michael Hampton 2009-12-16 14:04:50 EST
I can confirm that xorg-x11-server-Xorg 1.7.3-1 build from koji fixes this issue for me as well. Using the nvidia 190.42 drivers from RPM Fusion. akmod-nvidia-190.42-1.fc12.4.x86_64
Comment 106 Mario Santagiuliana 2009-12-16 17:05:19 EST
Packages from koji resolve my problems. Now I can use the proprietary driver. The nouveau driver works fine too.

I don't use compiz but only kwin.

I have got just one problem, when I suspend to ram, sometime(I don't know the exact sequences to reproduce this issue) the composition with kwin can't be enable or re-enable. If it start I have got a black screen with only mouse pointer, I must use the combination key (maiusc+alt+f12) to disable the "composition" and restore the correct visualization.
Other times I have got problem with combination-keys to start programs of kde.
It seems kde's bug...isn't?

Thanks to all.

My card:
$ lspci |grep -i vga
01:00.0 VGA compatible controller: nVidia Corporation GeForce 8600M GT (rev a1)

$ uname -r

$ rpm -q akmod-nvidia

$ rpm -qa|grep xorg-x11-server
Comment 107 Adam Williamson 2009-12-16 19:26:31 EST
Thanks to everyone. At this point we don't really need any more +1s - we're very sure the fix works. The issue now is just issuing an update; we will do this, but by this point we have a very big list of changes, so we have to be quite careful before issuing an update (or even an update candidate). We're currently getting some preliminary testing done before we pick a build to send out as an update candidate, but it will happen. Thanks again for testing.

Fedora Bugzappers volunteer triage team
Comment 108 Paulo Penteado 2009-12-16 19:43:19 EST
I installed xorg-x11-server-Xorg-1.7.3-2.fc12.x86_64, and it still only fixes the problem if Compiz is disabled.
Comment 109 Eli Wapniarski 2009-12-17 00:26:14 EST
xorg-x11-server-Xorg-1.7.1-12.fc12 did the trick for me.
Comment 110 Davide Rondini 2009-12-24 06:20:20 EST
I had the same problem. Installing  xorg-x11-server-Xorg-1.7.1-12.fc12 for me fixed it only partially. the menu now works fine, but some other KDE parts still present a hard delay responding to user interaction. It seems to be related to some plasmoids, not to Kwin. For example, krunner, yakuake and the recent devices manager appear slowly, but with the fix, the "classic" menu and the windows now work fine.
Comment 111 Eelko Berkenpies 2009-12-29 03:09:41 EST
I would be interested in a status update (any progress/luck picking an update candidate?), anyone? :)

Ps. I guess I don't have to +1 for another case where -12 fixes a system? ;)
Comment 112 Yiorgos Stamoulis 2010-01-04 06:58:23 EST

fixed the issue for me.  No side-effects (yet?)
Comment 113 Artem S. Tashkinov 2010-01-04 07:53:44 EST
The newest xorg-x11-server package is always available here:
Comment 114 Adam Williamson 2010-01-04 10:01:12 EST
@111:it's usual that little happened lately, Red Hat more or less shuts down over the Christmas period (25th Dec -> 2 Jan) so we haven't really been around to work on this. Things should pick up again in the coming week.
Comment 115 Robin 2010-01-05 12:37:55 EST
I just installed the latest test package from the above link and response it great.  I still have to fully test but I just wanted to say at least things seem much faster.
Comment 116 Sergei LITVINENKO 2010-01-05 13:27:36 EST
1.7.3-5.fc12 work OK for me

[sergeil@homedesk ~]$ lspci | grep 8800
01:00.0 VGA compatible controller: nVidia Corporation G80 [GeForce 8800 GTX] (rev a2)

[sergeil@homedesk ~]$ uname -r

Recent nvidia proprietary driver from rpmfusion.
Comment 117 Davide Rondini 2010-01-05 15:22:58 EST
Ok, I've installed xorg 1.7.3-8.fc12.x86_64 and now everything works fine for me.
Comment 118 Alex Tunc 2010-01-12 08:47:27 EST
I installed xorg-x11-server-1.7.4-1 with 190.53 nvidia drivers I can confirm desktop-effects not working but general usage seems good and fast.
Comment 119 Alex Tunc 2010-01-12 09:23:18 EST
 Edit:  sometimes system tray and window icons disappears  

(In reply to comment #118)
> I installed xorg-x11-server-1.7.4-1 with 190.53 nvidia drivers I can confirm
> desktop-effects not working but general usage seems good and fast.
Comment 120 nucleo 2010-01-12 14:35:22 EST
(In reply to comment #118)
> I installed xorg-x11-server-1.7.4-1 with 190.53 nvidia drivers I can confirm
> desktop-effects not working but general usage seems good and fast.    

With nvidia 190.42 and xorg 1.7.4 effects are working here.
Comment 121 Gilboa Davara 2010-01-14 04:11:35 EST
Latest update seems to have broken nVidia again.
I'm getting glacier-like performance since the last xorg-X11 update.

- Gilboa
Comment 122 Gilboa Davara 2010-01-14 04:12:48 EST
Jan 13 16:29:58 Updated: xorg-x11-server-common-1.7.4-1.fc12.x86_64
Jan 13 16:31:29 Updated: xorg-x11-server-Xorg-1.7.4-1.fc12.x86_64
Jan 13 16:31:54 Updated: 1:xorg-x11-drv-nouveau-0.0.15-18.20091105gite1c2efd.fc12.x86_64
Jan 13 16:32:43 Updated: xorg-x11-server-Xephyr-1.7.4-1.fc12.x86_64
Comment 123 Alex Tunc 2010-01-14 08:22:14 EST
I can confirm latest nvidia beta driver 195.30 with 1.7.4-1 xorg desktop effects working again!  still testing..
Comment 124 Adam Williamson 2010-01-15 16:10:04 EST
gilboa: what NVIDIA driver are you using exactly?

Fedora Bugzappers volunteer triage team
Comment 125 Gilboa Davara 2010-01-16 11:17:26 EST
$ cat /proc/driver/nvidia/version
NVRM version: NVIDIA UNIX x86_64 Kernel Module  190.53  Wed Dec  9 15:29:46 PST 2009
GCC version:  gcc version 4.4.2 20091222 (Red Hat 4.4.2-20) (GCC)

I tried switching back to 190.42. Showed the same behavior.
I tried switching to GNOME (from KDE 4.4rc1) - with or without compiz - dog slow.
Gone back to xorg-x11-server-Xorg-1.7.3-1 from koji and everything is back to normal.

- Gilboa
Comment 126 Eli Wapniarski 2010-01-16 12:25:27 EST
I might be writing something dumb but if you've installed the latest xorg server packages while still in run level 5 try to do it after dropping down to run level 3 and see if the problem persists.

Comment 127 Eli Wapniarski 2010-01-16 12:27:42 EST
Oh... and after installing the xorg server packages rebuild the nvidia driver. I'm assuming that you are using the drivers supplied by Nvidia and not RPMFusion.

Comment 128 Gilboa Davara 2010-01-17 03:44:51 EST

I usually drop to init 3 and back once I do anything that remotely relates to Xorg or nVidia-binary.
As for the drivers, I'm using the latest -testing RPMS in RPMFusion-nonfree. (Tried the latest stable, too)

- Gilboa
Comment 129 Pavel 2010-01-17 10:34:49 EST
I can't use my Radeon VE AGP videocard in dualhead configuration in Fedora 12.
Comment 130 Mario Santagiuliana 2010-01-17 11:35:16 EST
This bug is for nvidia card and kde problems. Not ati radeon.
Comment 131 Eli Wapniarski 2010-01-17 12:24:14 EST
(In reply to comment #128)
> Eli,
> I usually drop to init 3 and back once I do anything that remotely relates to
> Xorg or nVidia-binary.
> As for the drivers, I'm using the latest -testing RPMS in RPMFusion-nonfree.
> (Tried the latest stable, too)
> - Gilboa    

One other thing that I can think of is that you might have the nouveau frame buffer running.

You can check this by running lsmod and seeing if "nouveau" module is running. If it is then then you will need to blacklist it by

1) adding the parameter dblacklist=nouveau to the "kernel" line in grub.conf
2) make sure that the file blacklist-nouveau.conf is sitting in /etc/modprobe.d and that the line "blacklist nouveau" and not commented out.
Comment 132 Gilboa Davara 2010-01-17 12:40:39 EST

nouveau is blacklisted.
Plus, as I said, I have no performance issues once I switch to the koji xorg build.

- Gilboa
Comment 133 Pavel 2010-01-17 18:07:18 EST

 Problems when using KDE with the proprietary NVIDIA graphics driver, some Radeon dual-head configurations, or nouveau with KMS disabled

A test build that should resolve this problem is available from Koji:
xorg-x11-server-1.7.1-12.fc12. If you are affected by this issue, please test this update and report your results to the bug report.

I have problems with xorg-x11-server-1.7.1-12.fc12 and my dualhead radeon card.
Comment 134 Robin 2010-01-18 11:23:54 EST
Just to repeat comment 113

The newest xorg-x11-server package is always available here:

There have been at least 15 changes since build 142860 and the latest is 
Comment 135 Pascal Patry 2010-01-18 13:35:06 EST
'yum update' is prompting to install 1.7.4-1, is this build still having the issue? I used the 1.7.1 build that was referenced inside the FC12 common bugs page and they indeed fixed the issue. Is this patch going to be contained in all the future builds?
Comment 136 Adam Williamson 2010-01-19 19:39:53 EST
pascal: 1.7.4-1 is fixed. all builds since 1.7.3 or so are fixed.

Fedora Bugzappers volunteer triage team
Comment 137 Pascal Patry 2010-01-19 19:46:08 EST
(In reply to comment #136)
> pascal: 1.7.4-1 is fixed. all builds since 1.7.3 or so are fixed.

thank you,
Comment 138 Mukund Sivaraman 2010-01-20 06:57:35 EST
FWIW, I verify that on an NVIDIA GeForce 7600 GS chip, and using the latest Fedora 12 update packages (xorg-x11-server-Xorg-1.7.4-1.fc12.x86_64 from the fedora-updates repo), and NVIDIA proprietary driver version 190.53, GNOME desktop with Compiz enabled works properly. KDE applications under GNOME desktop such as Okular seem to work fine too. This is a fully updated Fedora 12 machine.

I was looking for a comment such as this before taking the plunge to update to 1.7.4. Hope this is helpful to others who want to try updating.
Comment 139 Gilboa Davara 2010-01-21 04:25:12 EST
Ran a full update (again), 1.7.4.
init 3, init 5, problem disappeared.
Now idea what happened the last time I tried updating to 1.7.4.
Comment 140 Artem S. Tashkinov 2010-01-27 14:14:21 EST
Please, close the bug, xorg in Fedora 12 was updated and includes a fix for this problem.
Comment 141 Adam Williamson 2010-01-27 14:29:10 EST
yeah, we can probably close this now. true.

Note You need to log in before you can comment on or make changes to this bug.