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 gnome-terminal 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): How reproducible: Always 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 Additional info:
>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 >gnome-terminal 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] XF86Config
Created attachment 88625 [details] XFree86.0.log
Created attachment 88626 [details] messages
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. Mr. Harris, 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 section?
This bug is closed period. Contact Nvidia at support for support for their driver.
Ok. Thanks for the information
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.