Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 78841

Summary: very slow on i810 without mem=
Product: [Retired] Red Hat Linux Reporter: D. Hugh Redelmeier <hugh>
Component: kernelAssignee: Arjan van de Ven <arjanv>
Status: CLOSED CURRENTRELEASE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 8.0CC: alan, michael
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-09-30 15:40:15 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
dmesg output on sluggish system (no mem= option specified)
none
dmesg output for normally behaving system (mem=240 option specified) none

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:
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:

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
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/