When compiling some not-too-big source code on a 32 MB beta3 system (no X running), the system starts trashing very quickly and doesn't come back within a reasonable time (at least one hour), so only the reset button helps. This is fully reproducable. The same test on the same HW config with RH 7.1 works fine.
This defect is considered SHOULD-FIX for Fairfax.
The problem still appears with kernel-2.4.7-0.3. I'll attach a file with 3 "top" snapshots just before the system stops reacting at all.
Created attachment 26031 [details] Top output of 3 stages before the system stops reacting
Is this the same bug as the one that causes very high inode_cache count in /proc/slabinfo?
maybe. I wonder if 2.4.7-0.5 or later behave better with 32Mb
Would like to try, if 0.5 is available somewhere...
ftp://ftp.beta.redhat.com/pub/rawhide/i386/RedHat/RPMS/ has -0.9.1 right now. BTW, as I mentioned in testers-list, I still see a very similar problem (and see very high inode_cache count at the same time) with 2.4.7-0.8 on 128Mb of RAM.
Tested with kernel 2.4.7-0.9.1: same problem :-(. And the inode_cache in /proc/slabinfo stays in the last 10 minutes of the system's life around these values: inode_cache 341 711 424 79 79 1 : 15113 38560 2064 3 0
I was still having these problems with 2.4.7-0.9.1, but with 2.4.7-0.13.1 things seem to be finally working normally.
Thanks for testing/confirming this. We'll continue to try to improve the VM, but without breaking the stability (I hope :)
Kernel 2.4.7-2 (current rawhide) does *not* seem to resolve our problems :-(.
Thanks for the bug report. However, Red Hat no longer maintains this version of the product. Please upgrade to the latest version and open a new bug if the problem persists. The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, and if you believe this bug is interesting to them, please report the problem in the bug tracker at: http://bugzilla.fedora.us/