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.
What video driver?
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"
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.
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.
Seems not fedora-specific either, http://bugs.archlinux.org/task/17037 xorg-1.7.1 + nvidia driver + kde = slow/badness.
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?
Too bad the arch report doesn't mention what fedora patch they're talking about. Anyway, here includes a possible workaround, http://forums.fedoraforum.org/showthread.php?t=233443
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?
Also, that workaround (Option "UseEvents") doesn't work for me as either "True" or "False".
That's part of xserver-1.7.1-window-pictures.patch re-assigning for comment/triage from x maintainers.
fwiw, the origin of that patch seems to come from bug #533236
no problems on my 32bit system. all reported cases seem to be on 64bit systems.
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: http://koji.fedoraproject.org/koji/taskinfo?taskID=1794560 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 https://fedoraproject.org/wiki/BugZappers
I can confirm that the above package fixes the problem for me. Good stuff!
Thank you for letting us know.
*** Bug 533805 has been marked as a duplicate of this bug. ***
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 https://fedoraproject.org/wiki/BugZappers
Reopening as it's clearly not fixed in Rawhide. I'd go for CANTFIX.
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/nvidia_drv.so (0x101a000+0x964d5) [0x10b04d5] Segmentation fault at address 0xa8416248 Fatal server error: Caught signal 11 (Segmentation fault). Server aborting
(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....
No problems with gwenview here. I just opened it and looked at a few pictures.
(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/nvidia_drv.so (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
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 nvnews.net, which is a sort-of semi-official NVIDIA driver support forum, NVIDIA employees monitor it. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Tagging for addition to the CommonBugs page
*** Bug 537008 has been marked as a duplicate of this bug. ***
Sorry, but I can't see how to get the rpms referred to in #13. Can someone tell me please?
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 ...
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).
Kevin: Thanks for the explanation Adam: Can you resubmit the build please or let me know where a copy was saved?
will do in a bit. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
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 https://fedoraproject.org/wiki/BugZappers
Here's a fresh scratch build like in comment #13 (which got garbage collected). http://koji.fedoraproject.org/koji/taskinfo?taskID=1812916 when it's done, I'll put it up in a repo somewhere for posterity.
Thanks Rex.
OK, as threatened, http://rdieter.fedorapeople.org/repo/
*** Bug 538275 has been marked as a duplicate of this bug. ***
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! :) [rdieter] name=xorg-x11-server rebuilds for nvidia users baseurl=http://rdieter.fedorapeople.org/repo/fedora/$releasever/$basearch/ enabled=1 gpgcheck=0
(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.
*** Bug 538344 has been marked as a duplicate of this bug. ***
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 :-(
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 https://fedoraproject.org/wiki/BugZappers
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 https://fedoraproject.org/wiki/BugZappers
(filed by nvidia,) documenting xorg upstream bug, https://bugs.freedesktop.org/show_bug.cgi?id=25136
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 2.6.31.6-134.fc12.x86_64 #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.
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 https://fedoraproject.org/wiki/BugZappers
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.
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: laptop ------------------------------------------------- HP Pavilion Entertainment PC (dv7) uname -a ------------------------------------------------- Linux vizzini 2.6.31.5-127.fc12.i686 #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, Pete
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!
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: http://lists.x.org/archives/xorg-devel/2009-November/003569.html
See also (cloned) bug #539768 , tracking the generally good feedback of testing the aforementioned patch ( from comment #48 ).
Can you please test this scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=1821848 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). Thanks! -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
=I can confirm that the rpms from the scrath build seems to solved the issue for me (NVIDIA proprietary 190.42-2).
I can confirm that the rpms from the scrath build seems to solved the issue for me (NVIDIA proprietary 190.42-2).
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?
*** Bug 539768 has been marked as a duplicate of this bug. ***
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 https://fedoraproject.org/wiki/BugZappers
couple of reports from the forums that the scratch build works well too (with proprietary driver). -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
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. Thank
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
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.
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.
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?
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.
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 https://fedoraproject.org/wiki/BugZappers
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.
Can you try 1.7.1-12? http://koji.fedoraproject.org/koji/buildinfo?buildID=142860 -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Yep, -12 fixes the problem here.
Simple patch, based on http://lists.x.org/archives/xorg-devel/2009-November/003569.html , over official version of xorg-x11-server packet, fix my problem. https://bugzilla.redhat.com/show_bug.cgi?id=537584
Going by the changelog, that patch is also part of the -12 package on Koji.
It's a long time since reporter said anything here. Could you please retest with packages from http://koji.fedoraproject.org/koji/buildinfo?buildID=142860, please? Anybody else, is there anybody who can reproduce THIS issue with the above linked package? Thank you
The -12 packages resolve the issue described in the initial report, yes. That's pretty much what everyone has been talking about in here.
I install the -12 packages and I have no X-crash when I work with Gimp. For me it's good...
>> >> Can you try 1.7.1-12? >> Yes, with xorg-x11-server version 1.7.1-12 from http://koji.fedoraproject.org/koji/buildinfo?buildID=142860 , KDE work as expected Thanks a lot.
*** Bug 537584 has been marked as a duplicate of this bug. ***
*** Bug 538836 has been marked as a duplicate of this bug. ***
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 https://fedoraproject.org/wiki/BugZappers
I can confirm, that 1.7.1-12 works just fine here. (xorg-x11-drv-nvidia-libs-190.42-4) Thanks & Cheers Serge
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.
It appears that nVidia's patch is included in the newly-released xorg-server 1.7.2, btw.
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?
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 https://fedoraproject.org/wiki/BugZappers
1.7.1-12 works for me (original bug reporter) as well, perhaps even faster than before. :)
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.
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 !!
>> 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. --- xorg-x11-server-Xorg-1.7.1-12.fc12.i686 xorg-x11-server-common-1.7.1-12.fc12.i686
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 :) Mitch.
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.
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.
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?
Thanks, I have created bug 544203.
I have created bug 544230
*** Bug 540064 has been marked as a duplicate of this bug. ***
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. [1] http://koji.fedoraproject.org/koji/buildinfo?buildID=146237
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
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.
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. http://www.nvnews.net/vbulletin/showthread.php?s=d952ded5f2bc3ad7fde6d2cea0282797&t=142478
>> Please commit the fix to updates or updates-testing. Or at least fix Koji! :] +1
(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. > http://www.nvnews.net/vbulletin/showthread.php?s=d952ded5f2bc3ad7fde6d2cea0282797&t=142478 NVIDIA driver cannot solve this problem.
(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. > > http://www.nvnews.net/vbulletin/showthread.php?s=d952ded5f2bc3ad7fde6d2cea0282797&t=142478 > > 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... https://fedorahosted.org/fedora-infrastructure/ticket/1845
(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... > https://fedorahosted.org/fedora-infrastructure/ticket/1845 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.
That UseEvents issue has absolutely nothing to do with this bug.
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 2.6.31.6-162.fc12.x86_64 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.
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
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.
+1 This works for me as well on my desktop system with nVidia drivers from rpmfusion: (mcpierce@mcpierce-desktop:~)$ rpm -qa *nvidia* kmod-nvidia-2.6.31.6-145.fc12.x86_64-190.42-1.fc12.6.x86_64 kmod-nvidia-2.6.31.6-162.fc12.x86_64-190.42-1.fc12.7.x86_64 akmod-nvidia-190.42-1.fc12.4.x86_64 nvidia-xconfig-1.0-1.fc12.x86_64 xorg-x11-drv-nvidia-libs-190.42-5.fc12.x86_64 nvidia-settings-1.0-3.2.fc12.x86_64 kmod-nvidia-2.6.31.6-166.fc12.x86_64-190.42-1.fc12.8.x86_64 xorg-x11-drv-nvidia-190.42-5.fc12.x86_64
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
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) Package: $ uname -r 2.6.31.6-162.fc12.x86_64 $ rpm -q akmod-nvidia akmod-nvidia-190.42-1.fc12.4.x86_64 $ rpm -qa|grep xorg-x11-server xorg-x11-server-common-1.7.1-12.fc12.x86_64 xorg-x11-server-utils-7.4-13.fc12.x86_64 xorg-x11-server-Xorg-1.7.1-12.fc12.x86_64
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 https://fedoraproject.org/wiki/BugZappers
I installed xorg-x11-server-Xorg-1.7.3-2.fc12.x86_64, and it still only fixes the problem if Compiz is disabled.
xorg-x11-server-Xorg-1.7.1-12.fc12 did the trick for me.
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.
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? ;)
xorg-x11-server-Xorg-1.7.3-1.fc12.x86_64.rpm xorg-x11-server-common-1.7.3-1.fc12.x86_64.rpm fixed the issue for me. No side-effects (yet?)
The newest xorg-x11-server package is always available here: http://koji.fedoraproject.org/koji/packageinfo?packageID=63
@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.
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.
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 2.6.31.9-174.fc12.i686.PAE Recent nvidia proprietary driver from rpmfusion.
Ok, I've installed xorg 1.7.3-8.fc12.x86_64 and now everything works fine for me.
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.
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.
(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. xorg-x11-server-Xorg-1.7.4-1.fc12.i686 xorg-x11-drv-nvidia-190.42-2.fc12.i686
Latest update seems to have broken nVidia again. I'm getting glacier-like performance since the last xorg-X11 update. - Gilboa
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
I can confirm latest nvidia beta driver 195.30 with 1.7.4-1 xorg desktop effects working again! still testing..
gilboa: what NVIDIA driver are you using exactly? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
$ 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
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. Eli
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. Eli
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
I can't use my Radeon VE AGP videocard in dualhead configuration in Fedora 12.
@Pavel This bug is for nvidia card and kde problems. Not ati radeon.
(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.
Eli, nouveau is blacklisted. Plus, as I said, I have no performance issues once I switch to the koji xorg build. - Gilboa
2mario_santagiuliana Problems when using KDE with the proprietary NVIDIA graphics driver, some Radeon dual-head configurations, or nouveau with KMS disabled http://fedoraproject.org/wiki/Common_F12_bugs#Problems_when_using_KDE_with_the_proprietary_NVIDIA_graphics_driver.2C_some_Radeon_dual-head_configurations.2C_or_nouveau_with_KMS_disabled A test build that should resolve this problem is available from Koji: http://koji.fedoraproject.org/koji/buildinfo?buildID=142860 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. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=533620 I have problems with xorg-x11-server-1.7.1-12.fc12 and my dualhead radeon card.
Just to repeat comment 113 The newest xorg-x11-server package is always available here: http://koji.fedoraproject.org/koji/packageinfo?packageID=63 There have been at least 15 changes since build 142860 and the latest is xorg-x11-server-1.7.4-4.fc12
'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?
pascal: 1.7.4-1 is fixed. all builds since 1.7.3 or so are fixed. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #136) > pascal: 1.7.4-1 is fixed. all builds since 1.7.3 or so are fixed. thank you,
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.
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.
Please, close the bug, xorg in Fedora 12 was updated and includes a fix for this problem.
yeah, we can probably close this now. true.