Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!gatech!prism!jb107
From: jb107@prism.gatech.EDU (Jim Burns)
Newsgroups: comp.os.minix
Subject: Re: 1.5 Demo disk broken ? (Problem solved)
Keywords: mined pipes scripts
Message-ID: <25624@hydra.gatech.EDU>
Date: 5 Apr 91 11:06:23 GMT
References: <25289@hydra.gatech.EDU> <25522@hydra.gatech.EDU>
Organization: Georgia Institute of Technology
Lines: 34

Kudos go to Paul Allen for the solution. He suggested 'cp /dev/ram
/dev/fd0' (I picked /dev/fd1) to make a proper copy of the root partition.
Thus with the copy in B: and the demo in A: and the boot menu on the
screen, type 'r' to set 'f1' as the root partition, and '=' to finish
booting. This freed up enough memory so that all my problems went away.
(There is one minor problem with 'df' - if you leave the ram disk size at
0 when you boot, 'df' says it can't locate the superblock on /dev/ram, and
if you make the ram disk size 10k, it says that /dev/ram is not a proper
filesystem. Apparently, /dev/ram is hardwired into the demo kernel areas
that df is looking at. The workaround is to just fully specify the file-
system devices that you want stats on.)

Andy Tanenbaum and Clarence Wilkerson pointed out the use of the F1 key to
monitor memory usage, and I was getting a lot of fragmentation. Paul also
pointed out that even tho' the procs are small, they can have up to 64k in
stack. Bruce Evans made a number of interesting suggestions that
unfortunately require tools that don't ship with the demo, like mknod and
dd. Of particular interest was:

   >there any way to reduce the size of the ram disk *after* booting? Any
   >ideas at all?

   Try reducing the size at offset 0x402 in /dev/ram. These bytes should be
   0xC0 0x00 now (192). Files above the new limit would be lost. It may help
   to remove unused files first (there aren't that many). It is best to run
   fsck to clean up the mess after changing the size. I supect fsck was too
   big to fit on the demo.

Thanx to all who responded.
-- 
BURNS,JIM (returned student & GT Research Institute staff member)
Georgia Institute of Technology, Georgia Tech Station 30178,
Atlanta Georgia, 30332            | Internet: jb107@prism.gatech.edu
uucp:	  ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!jb107