peter@ditmela.oz (Peter Kay) (11/28/88)
We have at last got Minix (1.3) to run reliably on our AST Premium
386. (It seemed the RIGHT machine to run Minix on!) Perhaps other
people may be interested in our experiences?
Our first attempts to boot the machine were with version 1.1. We
found that the machine would hang after typing the '='. Two
suggestions were found from previous news items to fix this problem.
1: to include a delay loop before the floppy disk controller was read
(this is now part of the 1.3 distribution). 2: to convert a LOCK
instruction which would cause problems on a 386.
Fix 1 allowed the floppy disk to start working. However we didn't
get very far! The floppy disk light would go on and the disk turn, but
eventually we would get the "I got a strange interrupt" message from
the kernel and the system would hang.
Our only clue to what was going on was that the sound of the disk
drive resetting itself is reasonably obvious, and before the message
came up we would hear one or two or maybe more resets.
The first fix to get us up and running was reasonably straight
forward. The floppy task has to try and figure out the right sort of
diskette in the drive. It does this by looping round each combination
until it gets the right one. In between each failure it resets the
drive. We produced a kernel (on a twin floppy machine with only 360kb
drives) that started off its loop of tries with the right combination.
(In this case a 1.2Mb floppy in a 1.2Mb drive). Success it worked!
The hard disk has a Western Digital controller and worked with no
trouble at all.
Well we were up and running but not very satisfactorily. Any time
we put a different density disk in the drive (which we needed to to
talk to the lowly twin floppy machine) the "strange interrupt" would
occur and the machine hang.
The solution? Well whatever it was, was occuring when the floppy
task was resetting the drive. When I looked at the code, the fdc specs
and the dma controller specs, it seemed that the dma controller was
being set up at the beginning of the transfer, and was not being
touched again until the setting up of the next (trial) transfer.
Perhaps, I thought, the dma controller chip was somehow responsible
for the strange interrupt? Maybe it was because that, although it was
set up ok for the transfer, when the transfer failed it was not being
told to abort it. Skipping through the specs I found the code for
resetting the controller and stuck a reset in the dma setup routine
before the controller was setup for the new transfer. Well this
worked quite well, but not all the time so I tried putting the dma
controller reset a little earlier in the retry loop and it now works
prefectly all the time.
The diffs for the floppy.c file are given below.
Peter Kay - peter@ditmela.oz.au
Andew Worsley - andrew@ditmela.oz.au
----------------------------------------------------------------------------
*** floppy.c_orig Mon Nov 28 11:58:47 1988
--- floppy.c Mon Nov 28 12:02:13 1988
***************
*** 234,239 ****
--- 234,240 ----
* means that we are trying at the wrong density. Try another one.
* Increment 'errors' here since loop is aborted on error.
*/
+ port_out(DMA_INIT, 6); /* reset the dma controller */
errors++; /* increment count once per loop cycle */
if (errors % (MAX_ERRORS/NT) == 0) {
d = (d + 1) % NT; /* try next density */
***************
*** 311,316 ****
--- 312,318 ----
if (top_end != top_addr) panic("Trying to DMA across 64K boundary", top_addr);
/* Now set up the DMA registers. */
+ port_out(DMA_INIT, 6); /* reset the dma controller */
s = lock();
port_out(DMA_M2, mode); /* set the DMA mode */
port_out(DMA_M1, mode); /* set it again */
----------------------------------------------------------------------------