jds@mimsy.UUCP (James DaSilva) (04/15/88)
In article <111@obie.UUCP> wes@obie.UUCP (Barnacle Wes) writes: >In article <1814@louie.udel.EDU>, C0033003%DBSTU1.BITNET@cunyvm.cuny.edu writes: ... >> After using it on ATs I'd like to bring MINIX to this new machine. But >> only the boot disk works. After start loading the root file system >> from the 2nd floppy the machine can only be reactivated by a hard >> reset ( power on ). > >This is the same behavior I've noted when trying to boot Minix on two >different 386 machines: AMT 386, with 64K SRAM cache, and Acer 1100, >using interleaved RAM. I've even tried slowing them to 6 MHz - still >didn't work. We began tracing the problem, and decided it probably >lives in the BIOS. We have some NEC APC IV's here, 2 with Rev A BIOS, >and 2 with Rev B BIOS. The two with Rev B boot Minix without >problems, the two with Rev A act the same as the 386s. If you folks are talking about Minix 1.1, then I know what your problem is. I found the problem last year when trying to get Minix working on my iSBC 386 AT (This is the generic 386 Motherboard provided to many clone makers). The function vid_copy in klib88.s (line 1731 in the source listing in The Book) executes the 'lock nop' instruction. This does nothing on a PC, but it signals the PC simulator that video memory has changed. On a 386, the lock prefix is restricted to certain instructions. 'lock nop' generates an undefined opcode trap to interrupt vector 6. Under Minix this points to the function _surprise in mpx88.s, which immediately calls unexpected_int() in main.c which tries to print the "unexpected interrupt" message, so the tty driver calls vid_copy ... You get the idea. Find a machine where you can rebuild the kernel and just comment out the lines lock | this is a trick for the IBM PC simulator only nop | 'lock' indicates a video ram access in _vid_copy, in klib88.s. Andy provided a fix for this in the 1.2 updates. >When you press `=' to tell the Minix loader program to load Minix, it >makes a BIOS call to do something (I can't remember what, and I can't >call anyone right now, obie is on the phone to wsccs). Apparently, >this BIOS call is where it dies. I think this BIOS call is only made >in the AT version of Minix. > > Wes Peters This isn't quite right. Minix is fully loaded before the initial menu comes up. fsck uses the BIOS to read and write disks. Once '=' is hit, fsck jumps to the kernel initialization code. Once the Minix kernel is running, the BIOS is generally abandoned. There is, however, one call to the BIOS get_equipment interrupt (int 0x11?) to tell the kernel whether to use the monchrome or color adaptors (and whether or not the machine is a PC or AT?) Of course, 386 AT compatibles are subject to the same incompatibility problems as other machines, so you may have other problems as well. For what it's worth, Minix 1.2 runs like a charm on my 386 AT. The CPU is 16Mhz and I think the bus is running at 8 Mhz. - Jaime ---------------------------------------------------------------------- usenet: uunet!mimsy!jds James da Silva internet: jds@mimsy.umd.edu "Stand on each other's shoulders, not on each other's toes."