negaard@aero.org (Eric Negaard) (02/07/90)
Minix arrived on my doorstep Friday afternoon a week and a half ago.
By Saturday night I had Minix 1.3 up and running on the following
hardware:
Gateway 2000 25 Mhz '386
1.2 Mb floppy
1.44 Mb floppy
150 Mb hard drive (CDC Wren III, ESDI, Western Digital 1007A ctlr)
4 Mb memory
Orchid ProDesigner VGA
It took me a little while to figure out how to get going -- the reference
manual had no mention of the /dev/at* devices, and the USER_GUIDE was
compressed and archived. Once I got the USER_GUIDE "unpacked" it was
pretty smooth sailing. I was able to create a 720 K filesystem on the
3.5" drive for some breathing room, then create hard disk partitions.
I put my Minix partitions at the "end" of the hard disk, a 3072 block root
(hd3) and about 32 Mb /usr (hd4). Fsck won't check either of these because
they start at blocks higher than 64 Mb. Why does fsck care where the
blocks sit physically -- doesn't it just use the raw device? Is it hard to
fix? I could (but don't really want to) repartition to move the Minix
filesystems up and put the DOS (4.01) filesystems at the end.
So my next step was to try to gather up the 1.5.0 diffs to build a new
system. Working several hours a day since last weekend I've finally
managed to get good versions of all of the postings. I've made these
available for anonymous ftp on aerospace.aero.org (130.221.192.10) in
pub/minix -- I'll leave them there as long as I can.
I unpacked all of the postings and patched the 1.3 sources and applied
fixes to some of the more major problems as noted in previous postings
(i.e. missing defines in include/dirent.h, misdeclaration of begsig in
include/lib.h, etc - I'm probably not remembering correctly on some of the
names). I also found a few of my own in the IBM strings package that
was posted later. Strlen.x had some garbage in the middle: it should
read (from memory)
...
repne
scab
not cx
dec cx
...
And strcmp.x has a statement that subtracts 21 from di. It should only
be subtracting 2 (i.e. change "sub di,21" to sub "di,2"). This fixes
the problem of ls not sorting files in directories properly (as well as
many other problems I'm sure).
Next I came to the task of building the kernel. I wasn't very sure
about some of the configuration options - so that may be why I'm
having the problems described below. I defined CHIP in minix/config.h
to be 386 (but I don't have klib386.x or mpx386.x). I compiled kernel,
fs, and mm which all linked fine so I assumed there were no problems.
I've only been reading this newsgroup since late December so I've
no doubt missed discussion about the protected mode and 386 specific
modifications. Are they documented somewhere?
First I tried making a boot disk on a double density diskette. This
didn't work very well at all - it would quit or get errors at different
stages of the boot process. Should this work? It doesn't seem like
I should have to "waste" a high density diskette for ~200K of boot image.
So I built a boot disk on a high density diskette and that works
reliably getting to the boot menu. Now here's where I'm puzzled: under
certain (reproducible) circumstances minix gets stuck just after printing
the message "RAM disk loaded ; please remove root disk . . .". Using
the F1 key reveals that time is being spent pretty much equally between
IDLE, MM, and /bin/sh. Every once in a while sh is waiting on MM then
it runs, then it waits on MM again then runs . . .
From what I have been able to determine it is dependent on
1) The kernel running in protected mode. If I set the
processor limit to 2 everything works fine.
2) The amount of memory available for the kernel to use.
The following table summarizes:
MEMORY SIZE MINIX RAM DISK SIZE MEMORY AVAILABLE MODE RESULT
------ ---- ----- --- ---- ---- ------ --------- ---- ------
4096K 147K 240K 3709K PROT HANGS
880K 147K 240K 493K REAL WORKS
4096K 147K 1200K 2749K PROT HANGS
4096K 147K 3072K 877K PROT WORKS
So it does work in protected mode if the 3 Mb of extended memory is used
by the RAM disk. I haven't tested RAM disk sizes between 1200K and 3072K.
If anyone can tell me what I might have done wrong I'll greatly
appreciate it.
I already love Minix and can tell that I'm in for a great time. Everyone
involved has done a superb job. To tell the truth I was surprised that
1.3 worked so well with my system "out of the box" -- although I don't
know what I would have done if it didn't work.
More questions:
o I have a Colorado Memory Systems "Jumbo 10" 1/4 inch
QIC-40 tape drive. Has anyone written a driver for this
or any other tape drive? If not this will probably be
my first project.
o Am I right in understanding that given the right compiler
Minix 1.5.0 supports 32 bit segment offsets, and therefore
arbitrarily large programs? Any PD compilers available?
o Assuming the answer to the last question is yes, has anyone
ported GCC to Minix? What about emacs?
Thanks for sticking with me this far,
Eric Negaard
negaard@aerospace.aero.org