From: haroldt@orion.yorku.ca
Subject: 3.51? && max memory of 2.4Megs?  HELP!!!
Organization: York University
Date: Mon, 14 Sep 1992 15:00:01 GMT


  (Forgive me if some of this sounds like I'm rambling.  I'm trying
to piece together in my mind all the data that I've gathered.)

  In short, I have a few questions:

0) How do I know if I'm running OS version 3.51 

1) How do I acquire 3.51?  

2) How do I get to create a process in excess of 2.5Megs?


  In detail.....

0)  I've been doing some digging on my 3B1 and started to wonder just
what I was running.  My /.version file indicates 3.5.  Would it say 
3.51 if I upgraded to 3.51 or is this a bad assumption?  How else can I 
find out what release I am at?

1)  Assuming I'm at 3.5, can someone get me access (electronically via
ftp is fine by me) to the 3.51 floppies?  Is the loader the same?  Can I 
just plop down a differant kernal and voila, 3.51?

2)  Now for the big one.  The one that started all this thought and 
ramblings....

  I've installed the 1.5Meg Eia/Ram card.  On the advice of others, I've 
ignored the cmbpcnt program that came with it.  I've modified the startup
routine cmb.rc to simply `/etc/lddrv/lddrv -a cmb`.  Someone told me (and my
documentation backs that up) that cmb came with 3.51.  It was not on my 
disk so I began to think about number 0 and 1 above.

  My box is now configured as follows:
	3B1 in custom housing
	67 Meg drive
	   almost 5 Meg swap partition (about 9800 blocks)
	3.5Megs memory
	   2 Megs memory on board
	   1.5Megs on Eia/Ram card
	3 serial ports
	   1 on board, 2 on card.

  Back to the process size thing...  I wanted to prove to myself that 
the entire 3.5Megs were available so I wrote a quick program to allocate
space.  It's a loop that allocates and repeats until an allocation fails.
It then prints the result (count of allocations) and cleans up.  In pseudo-
code it would look something like this (note: it is in C, compiled both with
gcc and with cc, same results).

  loop_begin:
	counter++
	malloc(1024) /* add to link list of allocated spaces */
	if successful, goto loop_begin

  print counter
  point to start of list

  cleanup:
	get next pointer
	remove current pointer
	point to next pointer
	if current pointer != NULL, goto cleanup

  end.


  The program reliably allocates 2460 units if run by itself with the 
debugging information intact (ie. not stripped).  I tried running it as 
root as well and got the exact same value.  2460 units of size 1024 
allocated.  2.4MEGS

  I wouldn't consider that unreasonable for a 3.5Meg machine except that there
is still 5Megs of swap available.  I proved to myself that it was swapping
by reformatting the swap partition and watching processes die. :)  As root, I
ran `newfs /dev/fp001` and each process exited at it's next convience.  A
`df /dev/swap` produced the same size information as `df /dev/fp001`.  Also,
when the process has allocated about 1700 units, the disk starts to run.  I'm 
sure it's swapping, almost.

  Some time ago, someone mentioned that there was a fixed maximum process size
of 4 Megs.  I'm nowhere near that.  I compiled with cc and gcc with the shared
library and gained an extra 6 units.

  Now for the really fun part.  Obviously this is not a process level restriction
because I tried running two processes.  Either both from the same account or
from two accounts, if I run two copies of memhog (appropriate name I thought),
one of the two exits at 1774, the other, just slightly behind it, continues to
2460 units.  This was run without the ua.  

  When run with a ua session running as well, the first exited at 1520.  Also 
noted was that I would get a "no processes" notice at times if I tried to 
do `ps -el` or anything else. 

  It's almost as if I'm not swapping, or perhaps, can't run a set of 
processes, the sum of which won't fit into memory.  What restrictions 
am I running into?  Any ideas/info would be welcomed.

Harold.t
Newsgroups: comp.sys.3b1