Bug 1448

Less vague report have the output of nvidia-bug-report.sh attached in.
Thx

For the record, I'm not experiencing such slowness myslef in other apps.
Is it only in emacs ?
what is the output of rpmlint emacs (or the emacs rpm package you are actually using).

Created attachment 507 [details]
Log generated by nvidia-bug-report.sh

(Don't pay too much attention to the /etc/issue file.  For some special reasons I still have an old fedora-release package.  But otherwise it is mostly an F13 system, with some selected pieces like emacs from the F14 test releases.)

I didn't know one could do rpmlint on installed packages too, but here is what it said:

mimmi$ rpmlint emacs
emacs.x86_64: W: name-repeated-in-summary C Emacs
emacs.x86_64: W: no-documentation
emacs.x86_64: E: non-standard-executable-perm /usr/bin/emacs-23.2 01755L
1 packages and 0 specfiles checked; 1 errors, 2 warnings.

To answer your question: Yes, emacs is the only application where I have noticed this.  Obviously, I haven't tried all possible applications.  On the contrary, the range I use might be somewhat smaller than many others'.  I use emacs for much and the command line for much.  So I'm not sure how much this observation is worth.  But I do run SOME other applications, and emacs is the only one which seems to trigger it.

Just to check if it made any difference, I upgraded to the F14 X server.  But it didn't help, the problem remains unchanged.

I'm now using

xorg-x11-server-Xorg-1.9.0-13.fc14.x86_64
xorg-x11-server-common-1.9.0-13.fc14.x86_64
xorg-x11-drv-nvidia-256.53-2.fc14.x86_64
xorg-x11-drv-nvidia-libs-256.53-2.fc14.x86_64
xorg-x11-drv-nvidia-libs-256.53-2.fc14.i686
xorg-x11-drv-evdev-2.5.0-1.fc14.x86_64

Can you reproduce with lastest 260 driver on F14 ?
(and lastest 2.6.35.6-39.fc14 kernel).

You need to run rpmlint on all (direct/indirect) dependencies of the emacs package.
rpm -qR emacs would list most of them.
What I'm searching for is an illegal usage of rpath that is forbidden in the whole fedora collection and could produce such issue for userland application.

Created attachment 508 [details]
Output from rpmlint on packages owning libraries loaded by emacs.

So an rpath in an application could cause the X server to use lots of cycles!  That, I wouldn't have guessed!

In order to catch all packages involved I did an lsof on a running emacs, extracted the "mem" files, did an "rpm -qf" on them, and ran rpmlint on the result.  If there are emacs dependencies containing for example only text files, they would not be included.  But anything where an rpath could be involved would be caught I believe.

I found one package which was a bit old where a executable, but not the actual library loaded by emacs, had an rpath.  To be on the safe side I upgraded it anyway.  After that I only find gconv libraries having rpath.  (And I trust the glibc people to know what they do, so I guess that is correct.)  I attach the output of that rpmlint run.

I have also upgraded kernel and nvidia packages:
kernel-2.6.35.6-39.fc14.x86_64
kmod-nvidia-260.19.06-1.fc14.x86_64
kmod-nvidia-2.6.35.6-39.fc14.x86_64-260.19.06-1.fc14.x86_64
xorg-x11-drv-nvidia-260.19.06-1.fc14.x86_64
xorg-x11-drv-nvidia-libs-260.19.06-1.fc14.x86_64
xorg-x11-drv-nvidia-libs-260.19.06-1.fc14.i686

None of this made any significant difference.  Emacs is still very slow, and Xorg goes very high in "top" when I do something in emacs.  It is hard to say if it is EXACTLY the same, but the problem is still very much there.

For verification I switched to the nv driver.  The problem did go away.

(In reply to comment #7)
> For verification I switched to the nv driver.  The problem did go away.
This doesn't mean anything by itself, it just mean nouveau or nv doesn't use a functione that trigger a bug in emacs. (or elsewhere).

Does something goes better with nvidia from rpmfusion-nonfree-updates-testing ?

"Verification" may have been the wrong word.  I probably should have said something like "another observation".

With rpmfusion-nonfree-updates-testing you refer to the F13 version I guess?  Since I moved to an F14 kernel on the testing machine (comment 6) it would mean a downgrade, and I'm not sure if that would have some negative consequences.  Other packages like selinux-policy sometimes depends on kernels being new enough.  It IS a testing machine, but I would not want to see it COMPLETELY out of order.

(For some reason, only one kernel at the time seems to be able to work with the Nvidia drivers, even if I have kmod-nvidia modules installed for all of them.  I've never figured out why this is, it has not been critical enough.)

What is the current status of this bug with f14 and 260.19.12 driver ?

> What is the current status of this bug with f14 and 260.19.12 driver ?

In a quick test I see no significant difference.  I'll need to test a bit more before I can say if it has changed at all, but it is very much a problem.

After a bit more testing, I can not say the upgrade to 260.19.12 made any difference at all for this problem.

from your report:

/etc/fedora-release
Fedora Core release 5 (Bordeaux)

[    53.825] (WW) Option "xkb_variant" requires an string value
[    53.825] (WW) Option "XkbVariant" requires an string value
[    53.825] (**) Option "xkb_options" "terminate:ctrl_alt_bksp,"

I guess you have upgraded from fedora Core 5 Until Fedora 13 ?
Can you verify for .rpmnew files ?
Also what is the content of /etc/X11/xorg.conf.d/00-system-setup-keyboard.conf

Created attachment 535 [details]
00-system-setup-keyboard.conf file

I have indeed upgraded release by release.  I avoid reinstallations.

Actually I have a cron job doing "locate .rpmnew" regularly to catch if I miss updating any configuration files, as well as a similar job for .rpmsave.  Just in case I ran the commands manually now, but there are no such files on the system at the moment.

FYI: I'm now trying 260.19.21, but there is no obvious difference.  The Xorg process still uses almost all of the CPU when I use emacs.  (And emacs is still the only client I've seen trigger this.)

By the way, I guess this is really an upstreams bug, not a bug in the packaging.  Should I send a bug report to Nvidia?  There is some email address to send reports to, I believe.  Or maybe you already have done that?

nvidia-bug-report.sh show the process to report a bug upstream.
Please do so and report feedback here.

Thx

Please report the problem upstream (as described in the nvidia-bug-report.sh ) and report feedback here.

That been said the content of the /etc/fedora-release is weird:
-----------------
Fedora Core release 5 (Bordeaux)
Kernel \r on an \m
-----------------
So this sugguest something went wrong with on or another package update.

Can you run the command:
yum list extras

About you xorg.conf:
With the lastest 260.x.x driver,(packaged from RPM Fusion), You only need this:
---------------

Section "Device"
        Identifier  "Videocard0"
        Driver      "nvidia"
EndSection

---------------
Others required options are located in /etc/X11/xorg.conf.d/

> Please report the problem upstream

I've created a thread: http://www.nvnews.net/vbulletin/showthread.php?t=157769  We'll see what that might give.

> yum list extras

As I've indicated, I have a number of old packages installed on the machine for various reasons.  The complete list is pretty long, and I don't think it would be appropriate to post it here.

I have tried to make sure everything that could be related to the X-server is up-to-date.  If that is not enough, it would probably be easier for me to make an additional parallel installation for testing purposes.  In case the posting on the Nvidia thread doesn't give any result, I'll try that.

Can you give a try on nvidia update to 260.19.36 using:
yum update --enablerepo=rpmfusion-nonfree-updates-testing kmod-nvidia\*

Thx

Unfortunately, there is no improvement with 260.19.36.

It's over a month since the last reply on the Nvidia forum thread, so I guess it's not too much hope to get more help there.  It's probably time to do a clean F14 installation and see if it still exists.  I'll try to free some space on the disk for a new partition.

A little update:

I've made a minimal install of a clean F14 system.  The bug does NOT appear there.

That could of course have several reasons.  It could be that something on my regular system is too old after all, and causes the problem. It could be that the new install is too minimal, and doesn't include some package that causes this.

I'll have to try to search for this, getting the systems closer until either the bug appears in the clean installation, or it disappears from the regular system.  But this will not be a quick process I'm afraid.  Maybe you want to close this issue until I can give more detailed information about what the trigger is.

The problem is that even your fedora-release isn't in good shape.
So maybe you can provides the outpout of :
# yum list extras
Which will list packages that are not in sync with current release
Or you can try compare the different configuration files, that might or not, be outdated with the current package default.
Anyhow there is a delta with the set of packages you have and the fedora default, but I don't think the problem will arise starting from a default set of packages for Xorg server support. I'm more in favor on a configuration offset.

Closing as worksfor'us' with current fedora.