Hello,
Seems you�re one step behind us ;-)
an installation of linux on a QuadPPRO machine with 1 GByte RAM was successful - just
�till we compiled a new kernel
with support for our (additional) RAID-Controler (ICP/Vortex) and bootet it.
mke2fs with the RAIDset on the ICP ended in 95% of the tries with an Ooops-Kerneldump.
The few times it finished, the partition was unusable because every restore with
verify on it gave us tons of miscompares
Because Linux is an operating system with excellent support ;-), we got this answer:
> Does anyone know about memory limitations for Linux?
Yup..
> In fact I have some trouble using an 2.0.35 while trying to make
> the system work with 1 Gig RAM..
>
> System init with 512 Megs seems to work fine: System is stable and
> running performant as expected..
The system needs a bit extra (64MB) for administrative
overhead. You should be safe using up to 960MB. A bit
more may work too, if you're lucky..
You can hack the kernel to support more than 1 GB of
memory, use include/asm-i386/page.h as a starting
point....
regards,
Rik -- the flu hits, the flu hits, the flu hits -- MORE
+-------------------------------------------------------------------+
| Linux memory management tour guide. [EMAIL PROTECTED] |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+
mfg Christian Heinz
mail : [EMAIL PROTECTED]
fon : +49 911 654 - 7539
fax : +49 911 654 - 3916
> ----------
> From: Dr. Michael Weller[SMTP:[EMAIL PROTECTED]]
> Sent: Donnerstag, 21. Januar 1999 11:20
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
>[EMAIL PROTECTED]
> Cc: Frantz, Chris
> Subject: Tar (but not cp) is incredible slow on certain dirs; request for
>comments/solution ideas/clues.
>
> Hi people,
>
> I've the following weird behaviour on a Compaq Proliant, 1Gig phys ram,
> Smart2 Compaq raid adapter with 6 disk Raid 5 array, 2 Xeon CPU's.
>
> I tried using both CPU's or only one (disabling it from the bios). I tried
> kernel 2.0.36 and 2.2.0pre7 (always with SMP compiled in (even when only 1
> CPU was used)). I also tried restricting the kernel memory to 64MB (side
> note: It appeared (!) to be a little faster with this setting, I assume
> handling/searching 1Gig of disk caches is much too slow. If it is not
> possible to speed the handling of cache memory up, maybe it is smarter to
> allow to set the kernel to use a maximum of n MB of buffer/caches memory.
>
> Anyway, effect under all those kernels/# of CPU's is as follows: I try to
> backup / (whole linux is in one partition) to another disk, file on same
> disk, or even /dev/null (it doesn't matter). It runs nicely. But when it
> comes to /usr/src/linux-2.2.0pre7 where the 2.2.0pre7 sources are, it
> slows down to a crawl. That means it backs up one of these really tiny *.c
> and *.h files there per 1 or 2 seconds. Basically, it is impossible to
> back this dir up in any reasonable time.
>
> I used tar -l as to exclude /proc and /mnt where the destination disk was
> mounted. Still, even 'tar -cvf/dev/null /usr/src' showed the exact same
> behaviour although it slowed down faster as it came faster to
> /usr/src/linux-2.2.0pre7 .
>
> During the slow down, top claims system is well over 90% percent idle,
> CPU time consumed by tar and general system time spent is virtually zero
> (1 or 2 %). Tar is not locked in an uninterruptible sleep waiting for a
> device ('D') nor is there any apparent high disk activity (it just gets
> these tiny files every few seconds).
>
> To make things even more weird, cp -rv /usr/src /mnt works like a greased
> weasel. So, a simple filesystem/disk cache/dname cache/disk device or
> driver issue can IMHO be excluded.>
>
> Now, honestly, this is the very first time with linux I really have no
> clue what's going on. Therefore any comments and ideas are appreciated.
>
> Michael.
>
> P.S. Files and disks are currently moved around a bit more on this
> machine. I'll see if the same holds when /usr/src/linux-2.2.0pre7 was
> moved to another partition.
>
> --
>
> Michael Weller: [EMAIL PROTECTED], [EMAIL PROTECTED],
> or even [EMAIL PROTECTED] If you encounter an eowmob account on
> any machine in the net, it's very likely it's me.
>
