Red Hat Bugzilla – Bug 78841
very slow on i810 without mem=
Last modified: 2008-08-01 12:22:53 EDT
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):
Steps to Reproduce:
1.boot RHL without mem=
2.notice system is sluggish (top takes 10-30% of CPU itself!)
Actual Results: system unusably sluggish
Expected Results: system is reasonably responsive.
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
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/