ok, confirmed -- it is _not_ PAE-related. Just using a plain highmem (4G)
support causes all these problems -- the machine becomes 38-40 times
slower overall and one of the eepro100 cards stops working.
I will try Zoltan's ideas on 64bit mtrrs but any more ideas are welcome...
Thanks,
Tigran
On Wed, 11 Oct 2000, Tigran Aivazian wrote:
> 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/
This archive was generated by hypermail 2b29 : Sun Oct 15 2000 - 21:00:17 EST