lkml.org 
[lkml]   [2000]   [Oct]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subject[more findings!] Re: test10-pre1 problems on 4-way SuperServer8050
Amazing, disabling highmem altogether (not just PAE) i.e. being able to
use only low 896M of RAM got rid of _both_ the eepro100 and slowness
problems!

The system is now very fast (kernel compile in 61 seconds!) and all
eepro100 interfaces work fine. I will now test with plain highmem (4G) but
no PAE... and see what happens

On Wed, 11 Oct 2000, Tigran Aivazian wrote:

> Hi,
>
> I have installed 2.4.0-test10-pre1 on a 4-way Xeon 700MHz 6G RAM machine
> and observe various problems, not present in
> 2.2.16-(redhat69's-number-17).
>
> a) one of the eepro100 interfaces (the onboard one on the S2QR6 mb) is
> malfunctioning, interrupts are generated but no traffic gets through (YES,
> I did plug it in correctly, this time, and I repeat 2.2.16 works!)
>
> b) it detects all memory correctly but creates a write-back mtrr only for
> the first 2G, is this normal?
>
> # cat /proc/meminfo /proc/mtrr
> total: used: free: shared: buffers: cached:
> Mem: 1985175552 107397120 1877778432 0 6864896 60833792
> Swap: 1891770368 0 1891770368
> MemTotal: 6132952 kB
> MemFree: 6028072 kB
> MemShared: 0 kB
> Buffers: 6704 kB
> Cached: 59408 kB
> Active: 9884 kB
> Inact_dirty: 56228 kB
> Inact_clean: 0 kB
> Inact_target: 96 kB
> HighTotal: 5322688 kB
> HighFree: 5247736 kB
> LowTotal: 810264 kB
> LowFree: 780336 kB
> SwapTotal: 1847432 kB
> SwapFree: 1847432 kB
> reg01: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
> reg02: base=0xfc000000 (4032MB), size= 64MB: uncachable, count=1
>
> c) /proc/meminfo shows the number of bytes incorrectly, The B() macro of
> fs/proc/proc_misc.c looks fine but perhaps the %8lu format specifier
> should be extended to %16lu? (we should care about correctness more than
> about binary compatibility with apps that may parse /proc/meminfo file)
>
> d) the system is incredibly slow. It took only 1 minute 20 seconds to
> compile the kernel (make -j4 bzImage, with mem=512M because the e820
> (or whatever is in 2.2.x, I don't care) algorithm didn't work so I
> gave it at least "some memory" to work with) on 2.2.16 and it took about
> an hour to compile on 2.4.0-test10. I expected 50 seconds or so.... Must
> be something to do with caching? I enabled PAE of course. It is probably
> something simple to fix as I expect this machine to be the fastest in the
> world (for this price :)
>
> I will slowly go through all of these problems, starting with the simplest
> c)
>
> Regards,
> Tigran
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:39    [W:0.100 / U:0.836 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site