Path: utzoo!mnetor!uunet!munnari!natmlab!basser!metro!ipso!runx!colinm
From: colinm@runx.ips.oz (Colin McCormack)
Newsgroups: comp.os.minix
Subject: Re: Problems with serial TTY driver
Message-ID: <1275@runx.ips.oz>
Date: 19 Dec 87 17:34:52 GMT
References: <2314@encore.UUCP>
Reply-To: colinm@runx.OZ (Colin McCormack)
Organization: RUNX  Un*x Timeshare. Sydney, Australia.
Lines: 39

In article <2314@encore.UUCP> paradis@encore.UUCP (Jim Paradis) writes:
>After many weeks of not quite being able to get around to it,
>I finally added serial line support to my rewritten MINIX TTY
>driver.  It works, but there's one serious problem: If I test
>it out by looping back transmit and receive on the serial line
>and running a quick&dirty terminal program, if I type at it
>too fast the system will hang.  Now, I remember someone else in
>this newsgroup sometime back who added serial capabilities to
>the stock TTY driver and ended up with the same problem.  Is there
>some limit to how fast MINIX will take interrupts?  If one takes
>them too fast, will messages get lost?

I am only working from the published version, and this may have been fixed 
in later minix versions (later than 1.1), but I think that 8088 interrupts
are re-enabled too soon in the function interrupt() in file kernel/proc.c.

As soon as interrupts are permitted an interrupt will cause the current
machine state to be stored in the process kernel table entry for the
process pointed at by the kernel global variable proc_ptr (which represents
the process table entry for the interrupted process.)

Since the process has effectively been suspended by the time the interrupt
function starts, and no new value for proc_ptr is selected until the current
interrupt handler finishes, the last thing we want is for the machine state
at interrupt() to overwrite the saved machine state at proc_ptr.  Doing this
will at least cause the pending process to effectively disappear - and if that
process was fs or mm.....

I suppose a solution would be to leave interrupts suspended until a new process
has been restarted, but this would degrade interrupt response time unacceptably.
This problem has arisen from my attempts to port minix to the 68000 (which has
prioritised interrupts) where we actually _want_ reentrant interrupt handling.

If there is a fault in my analysis of minix interrupts, I'd appreciate hearing
about it, also if anyone has already hacked minix for 68000 I'd like to know
what tack you took to avoid this problem.

Colin McCormack.
[insert pithy comment here]