Path: utzoo!mnetor!uunet!munnari!otc!metro!ipso!runx!brucee
From: brucee@runx.ips.oz (Bruce Evans)
Newsgroups: comp.os.minix
Subject: Re: system hanging after boot
Message-ID: <1477@runx.ips.oz>
Date: 17 Apr 88 19:07:26 GMT
References: <1931@louie.udel.EDU>
Reply-To: brucee@runx.OZ (Bruce Evans)
Organization: RUNX  Un*x Timeshare. Sydney, Australia.
Lines: 51

Detlef J. Schmidt <C0033003%DBSTU1.BITNET> writes:

>>From:         Barnacle Wes <wes@obie.uucp>

>>When you press `=' to tell the Minix loader program to load Minix, it
>>makes a BIOS call to do something (.......)  Apparently,
>>this BIOS call is where it dies.  I think this BIOS call is only made
>>in the AT version of Minix.

The BIOS call is just get_chrome() to see if there is a color monitor. Like
most BIOS calls, the first thing it does is a "STI" instruction to enable
interrupts. It is called right in the middle of kernel/main(), just before
replacing the vector table. This violates the lock() made at the beginning
of main().

Usually this causes no problem because the only active vectors belong to
the BIOS and point into ROM. It is possible that some BIOS's do something
more creative, but I can't think of anything reasonable which would hurt.

I had problems with this when loading Minix directly from DOS, using an
improved version of a program posted by Marty Leisner. The program now
relocates Minix to low memory to avoid losing the "small" amount of 128K+.
This makes the vector table invalid (DOS has been overwritten) and the "STI"
in get_chrome() bites.

To fix this, I used the interrupt controller to disable interrupts more
securely:
    port_out(INT_CTLMASK, ~0);
    port_out(INT2_MASK, ~0);
This belongs with the lock() at the start of kernel/main(), or even earlier
with the redundant locks in the assembler startup.

There's also a problem with the way Minix enables ALL interrupts at the
controller level later on (writing 0 to the controller where ~0 was above).
As soon as the restart() at the end of main() is done, interrupts are
enabled, and this is before any of the tasks (interrupt handlers) have been
initialized. The standard Minix handlers seem to cause no trouble, but
problems with mouse interrupts (?) have already been reported. I had problems
with a tty driver. It took the port address 0 from an unininitialized table
and did i/o to it. Not safe when that port has something to do with DMA.

The right way to set up the interrupt controllers is to leave each bit set
until the corresponding driver has been initialised, and let the driver
worry about clearing it. I use a function
    PUBLIC enable_int( unsigned vec_nr );
to take care of this, and a function
    PUBLIC set_int( unsigned vec_nr, vir_bytes (*addr)(), phys_clicks seg );
to set up a vector and enable it in one step.

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