[comp.os.minix] MINIX on the Zenith 150

n0ano@wldrdg.UUCP (04/06/87)

This posting is an account of my experience in putting MINIX
on a Zenith 150.  My Zenith is an IBM PC/XT clone with a single
floppy and a 10 Mbyte hard disk.

The good news is the MINIX works just fine on the floppy.  I
followed the instructions and every thing worked exactly as
advertised.

The bad news is the hard disk.  The hard disk works fine as a
read-only device.  It dies when you try to write to it.  The fun
part is that it doesn't die immediately.  You write a random number
of blocks and then the disk driver fails to write a block, trys to
reset the disk, fails to get the proper status back from the reset
and so the disk driver goes into a loop constantly resetting the
disk.

I've sliced my disk up into four partitions.  Partition 1 (6 Mbytes)
is used for MS/DOS, Partition 2 (3 Mbytes) will be used for MINIX, and
Partitions 3 & 4 (374 Kbytes) are for general utility.  What I did
was write an MS/DOS program that copied the MINIX /usr file system
to Partition 4 and I now use Partition 4 as the /usr file system when
I boot MINIX.

Using this scheme I've successfully re-created the MINIX kernel from
the sources provided.  The kernel created under MINIX works but it is
about 6 Kbytes bigger than the kernel distributed by P-H (the boot
image size goes from 89K to 96K).  Looks like the PC/IX C compiler
is a little more efficient than the MINIX one.

Don Dugger
Wildridge Consulting
nbires!onecom!wldrdg!n0ano

go@orstcs.UUCP (04/10/87)

(I hate repeating base notes...)

This is in response to n0ano at wldrdg.UUCP regarding hard-disk promblems
on his 150 system.  I also experience the same problem on my XT clone
(uses WD 1002-WS2 controller with 20 M 225 type disk).  Reads (*lots* of
reads  MMMMEGAbytes of reads) work fine.  But sometimes when writing
the driver gets out of sync with the controller.  My theory (having
not manual for the controller -- yet) is the following:

	Driverer issues request for interrupt to occur upon
	DMA completion.  On reads, DMA completion means the
	entire transfer is complete: read from disk to controller,
	then DMA reads from controller into XT memory.

	On writes, a DMA completion simply means data has been loaded
	into controller's buffer -- disk is only then starting to
	write the data.  If another request is made for disk service
	while the data is being written to the disk, the controller
	simply won't answer.  Driver responds by resetting it and
	starting over.

Evidence collected confirms the above.  Sometimes when the errors
occur, there are blocks that haven't been written to the disk
(pieces of files are "different").

Slow speed writes never seem to cause the problem.

I was working on some attempts at fixing these problems (more like
groping in the dark without documentation on controller -- but that
is on it's way, I hope) but ran into a problem -- The system won't
run at all on the hard disk when I run the version I compile.  Note
that I haven't changed a thing except one tiny mask in the tty
driver refering to the Video Memory.  I tried simply compiling
xt_wini.c and no soap.

When I get my documentation and try a few more things, I'll be sure
to let you all know (if someone else hasn't fixed it sooner).

Gary Oliver
...!hplabs!hp-pcd!orstcs!go