From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:0.9.9) Gecko/20020408
Description of problem:
Running multiple mozilla browsers, sessions in konsole (or multiple gnome
terminals) with a screen history set to 100,000 causes the box to use almost all
256M of physical memory and over 300M of swap.
Switching desktops in kde or windowmaker is a pain and exiting from a terminal
renders the box almost useless as I wait for the disk activity to stop. Screen
updates are slow and cause disk activity even with a few lines in konsole or
mozilla, X and kdeinit (or gnome-terminal when I am using windowmaker and
gnome-terminal) are the largest memory hogs with kdeinit or gnome-terminal
taking the crown followed by mozilla.
I did not have it this bad in RH 7.3. I did have to close some terminals from
time to time then but I could close them pretty quickly without disk activity
temporarily rendering the box unusable.
At least it never crashed on me in 8.0
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Open some mozilla browsers
2. Open evolution
3. Open konsole
4. Set history to 100,000 lines
5. Open some terminals in konsole
6. Use it like this and later you're swapping with every line that runs down a
terminal session (disk activity before the line is drawn)
Actual Results: Slow response in terminals, slow response in everything
Expected Results: Things were much snappier in 7.3. Closing terminals to reduce
memory usage or closing browsers were done in seconds not minutes
>Switching desktops in kde or windowmaker is a pain and exiting from a terminal
>renders the box almost useless as I wait for the disk activity to stop. Screen
>updates are slow and cause disk activity even with a few lines in konsole or
Disable font antialiasing. None of the drivers hardware accelerate RENDER
operations, so font antialiasing is done by your CPU. This can noticeably
slow down some systems.
>mozilla, X and kdeinit (or gnome-terminal when I am using windowmaker and
>gnome-terminal) are the largest memory hogs with kdeinit or gnome-terminal
>taking the crown followed by mozilla.
And you're getting that information from "top", which is bogus. The X
server consumes very little memory, contrary to what top says. The total
memory usage given by top, includes among other things, video memory, which
is memory mapped, memory mapped I/O register space on your video board, and
perhaps other resources like video BIOS, etc.
Also, X resources are stored *inside* the X server. Any client application
such as mozilla, etc. that allocates large pixmaps, ends up enlarging the
X server's memory space because those pixmaps are stored in the X server.
Almost all "X is memory leaking" bug reports in reality are "mozilla is
leaking pixmaps, which are X resources stored in the X server, and makes
X look like it is huge" when in fact it is not.
>I did not have it this bad in RH 7.3. I did have to close some terminals from
>time to time then but I could close them pretty quickly without disk activity
>temporarily rendering the box unusable.
The X server has not changed much at all from RHL 7.3 to 8.0 except for
bug fixes. Any changes that you are seeing are most likely GNOME/KDE
related, or application specific bugs, and not XFree86 specific issues.
It's also possible it could be a kernel issue perhaps.
There is not really anything I can do about this as I don't believe
there is an XFree86 bug/problem at play here, and I most certainly do not
have any such problem on my own systems.
Please attach your X server log, config file, and /var/log/messages file.
Make sure the messages file contains bootup information from your last
boot also, and include logrotated ones as well if need be, so I can
see your full kernel bootup sequence.
Setting your history to 100,000 lines seems to be an awful lot of wasted space:
<top report after running ls -R / in konsole>
25990 myohe 15 0 81408 40M 10484 R 5.0 5.3 0:13 konsole
Created attachment 88624 [details]
Created attachment 88625 [details]
Created attachment 88626 [details]
Michael, never you mind the 100,000 lines. I use that for a reason. Besides, the
effect of that on 7.3 was not too adverse. Oh, I use the Nvidia driver for the
Asus Combat (whatever) TNT-Vanta card and not the XFree86 one.
Can you explain why lines sent to a terminal cause disk activity? tailing logs
on 8.0 is really choppy compared to 7.3 (not that I could follow the stuff on
7.3) I now run with no history and so I do not have problems now.
I am almost positive that this bug will be handed off to Bug 78616 - "A binary
only kernel module was in use when something bad happened". You should see if
you have the same behaviour with the stock XFree86 nVidia driver (the one that
is supported by Red Hat).
it's probably going to be 73733 :)
however since the erratum 7.3 kernel and 8.0 kernels are identical... we can
rule out kernel interaction
Arjan's synopsis is correct. You are using proprietary kernel modules
that Red Hat did not ship, and Red Hat does not support.
*** This bug has been marked as a duplicate of 73733 ***
gee. I have quite a few colleagues that downgraded from 8.0 back to 7.3. They
didn't use any proprietory drivers but they all ran into similar problems. Like
Arjan said, we can rule out kernel interaction (hmm does that count third-party
drivers?). Anyway, I used the same Nvidia drivers in 7.3 and 8.0 if that helps
at all in this particular case....
No, it does not rule out 3rd party drivers. Arjan is ruling out Red Hat kernel
which does not contain 3rd party drivers. 3rd party drivers can do absolutely
anything to the kernel, and even if they're rmmod'd they could have modified
anything in the running kernel prior to that.
The binary only Nvidia kernel code is compiled with egcs 2.91.66, and Nvidia
so far has refused to use any other compiler. The Red Hat kernel is compiled
with gcc 3.2 in RHL 8.0. The Linux kernel does not have a kernel module ABI,
and as such gives no ABI guarantees. All of the code in a running kernel must
be compiled by the same major version of the gcc compiler. It is a known
fact, that gcc 2.x compiled kernel code is not compatible with gcc 3.x kernel
code. Once Nvidia acknowledges this, and recompiles their drivers with
gcc 3.x for use in gcc 3.x compiled kernels instead of ignoring the problem,
perhaps users won't have so many problems when using their drivers.
Well then is this bug still open? Or do I have to pull out the Nvidia driver
from loading during start up and use the XFree86 provided driver?
oh, if this is not a kernel nor a XFree86 bug will it be moved to an appropriate
This bug is closed period. Contact Nvidia at email@example.com for support
for their driver.
Ok. Thanks for the information
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.