From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 Description of problem: Installing and running RHL8.0, even with the updated kernel is very slow on my system. As if the cpu were a tenth the speed, or worse. The CPU is a 700MHz Celeron on an MSI 6183 motherboard. This uses the Intel 810 chipset -- integrated audio and video. Although it has 256M of RAM, I found that performance became reasonable when I added mem=240M kernel option. I've not tried other sizes. RHL7.1, Knoppix 3.1, and MS Windows 98SE do not have this problem (or at least don't manifest this symptom). I will include dmesg output for a run without mem= (sluggish) and with mem= (normal). I unplugged an unrecognized USB device between runs -- ignore the hub.c and usb.c lines that changed. I don't understand why the cd-write switched from dma mode to pio mode. The BIOS version is 1.7, the latest available from MSI. I don't know if the BIOS is lying to the kernel about memory layout. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.boot RHL without mem= 2.notice system is sluggish (top takes 10-30% of CPU itself!) 3. Actual Results: system unusably sluggish Expected Results: system is reasonably responsive. Additional info:
Created attachment 87008 [details] dmesg output on sluggish system (no mem= option specified)
Created attachment 87009 [details] dmesg output for normally behaving system (mem=240 option specified)
That sounds like a BIOS memory setup bug - one or two bioses dont set the mtrr registers right. On windows low memory is used first, on Linux high first so it shows up more obviously in Linux. Can you attach 'cat /proc/mtrr'
/proc/mtrr is the doesn't change with the mem= option. Here it is: reg00: base=0x00000000 ( 0MB), size= 128MB: write-back, count=1 reg01: base=0x08000000 ( 128MB), size= 64MB: write-back, count=1 reg02: base=0x0c000000 ( 192MB), size= 32MB: write-back, count=1 reg03: base=0x0e000000 ( 224MB), size= 16MB: write-back, count=1 reg04: base=0x0f000000 ( 240MB), size= 8MB: write-back, count=1 reg05: base=0x0f800000 ( 248MB), size= 4MB: write-back, count=1
I think I may have a similar problem on my box at home. Alan touched that Linux has this problem more so than Windows (which is exactly right). My MTRR information looks pretty horked to me: $ cat /proc/mtrr reg00: base=0x00000000 ( 0MB), size= 256MB: write-back, count=1 reg01: base=0x10000000 ( 256MB), size= 128MB: write-back, count=1 reg02: base=0x00f00000 ( 15MB), size= 1MB: uncachable, count=1 reg03: base=0xd6000000 (3424MB), size= 4MB: write-combining, count=1 The "reg03" entry looks nasty. Is there a work-around for this problem?
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/