Path: utzoo!mnetor!uunet!munnari!otc!metro!ipso!runx!brucee
From: brucee@runx.ips.oz (Bruce Evans)
Newsgroups: comp.os.minix
Subject: Re: MINIX 1.2 on a 386-based machine?
Message-ID: <1437@runx.ips.oz>
Date: 18 Mar 88 16:38:23 GMT
References: <1569@louie.udel.EDU>
Reply-To: brucee@runx.OZ (Bruce Evans)
Organization: RUNX  Un*x Timeshare. Sydney, Australia.
Lines: 57

Minix runs normally on my 386. It took only a small modification to the floppy
driver.  The AT hard disk driver was no problem. fdisk and fsck gave minor
problems.

My machine is a Micronics motherboard in an AT clone case with AT compatible
I/O. My software is a much hacked V1.2+ kernel, originally on a 360K disk.
This shouldn't have helped but I'm not sure. I use faster routines to write
to the I/O ports, but this hurts because the 386 is sometimes too fast.
Perhaps there are less bugs.

Floppy disk problems
--------------------

The floppy root file system was initially unreadable. A long session with my
debugger gave the following patch.

Line approx 485 in floppy.c fdc_results(), just before the line
   port_in(FDC_STATUS, &status)
add a delay loop
   {
      int k;
      for ( k = 0; k < 256; ++k )
         ;
   }
Here 256 is far to many. I think 4 works but am still running with 256. I
don't know exactly why this works! Obviously the 386 is hitting the status
port too fast, but a disassembly of the BIOS showed shorter (programmed)
delays than the slow C code was doing naturally.

No doubt other machines will have other problems. The "trap < 16" message
could be a BIOS problem, but more likely an uninitialized interrupt.

Another thing worth trying is to reduce the machine's speed to avoid timing
problems. If there is no hardware switch, this involves finding how to in
software and doing it in kernel/main().

Hard disk problems
------------------

These have nothing to do with the 386, just with DOS 3.3 and disks > 32 MB.

fdisk has a hard-coded head count of 4, my new drive has 6. People have
reported problems with 5 heads instead of 4 but they must have been in
the XT driver. (My driver is the latest official one that I know of).

fdisk doesn't completely understand all the codes DOS fdisk uses. I previously
had problems with DOS 3.2 fdisk. It gave division by zero crashes on bad
partition tables. The 3.3 version just hangs with what fdisk naturally writes.
I ended up creating a 2nd DOS partition (new ability for 3.3) and zapping it
by hand so DOS does not see it (I hope).

The standalone fsck can't handle block numbers > 64K. It is supposed to give
an error message to that effect, but instead tried to access some unknown
unreadable block. I used a posted Minix version which worked fine.

Bruce Evans
Internet: brucee@runx.ips.oz.au    UUCP: uunet!runx.ips.oz.au!brucee