Bug 78841 - very slow on i810 without mem=
Summary: very slow on i810 without mem=
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 8.0
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2002-12-01 22:54 UTC by D. Hugh Redelmeier
Modified: 2008-08-01 16:22 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2004-09-30 15:40:15 UTC

Attachments (Terms of Use)
dmesg output on sluggish system (no mem= option specified) (7.34 KB, text/plain)
2002-12-01 22:56 UTC, D. Hugh Redelmeier
no flags Details
dmesg output for normally behaving system (mem=240 option specified) (7.45 KB, text/plain)
2002-12-01 22:57 UTC, D. Hugh Redelmeier
no flags Details

Description D. Hugh Redelmeier 2002-12-01 22:54:57 UTC
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:

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.

Additional info:

Comment 1 D. Hugh Redelmeier 2002-12-01 22:56:22 UTC
Created attachment 87008 [details]
dmesg output on sluggish system (no mem= option specified)

Comment 2 D. Hugh Redelmeier 2002-12-01 22:57:37 UTC
Created attachment 87009 [details]
dmesg output for normally behaving system (mem=240 option specified)

Comment 3 Alan Cox 2002-12-02 12:33:53 UTC
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'

Comment 4 D. Hugh Redelmeier 2002-12-03 03:42:03 UTC
/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

Comment 5 Michael Lee Yohe 2002-12-04 17:54:02 UTC
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?

Comment 6 Bugzilla owner 2004-09-30 15:40:15 UTC
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/

Note You need to log in before you can comment on or make changes to this bug.