Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wasatch!cs.utexas.edu!tut.cis.ohio-state.edu!bloom-beacon!gatech!purdue!decwrl!sun!pitstop!sundc!seismo!uunet!mcvax!hp4nl!botter!star.cs.vu.nl!ast
From: ast@cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.os.minix
Subject: Re: Minix for the PS/2
Message-ID: <2015@ast.cs.vu.nl>
Date: 8 Feb 89 09:19:04 GMT
References: <1054@uvm-gen.UUCP> <12117@dartvax.Dartmouth.EDU>
Reply-To: ast@cs.vu.nl (Andy Tanenbaum)
Organization: VU Informatica, Amsterdam
Lines: 40

In article <12117@dartvax.Dartmouth.EDU> stevel@eleazar.dartmouth.edu (Steve Ligett) writes:
>Ok, there are [3] methods of handling PS/2 interrupts that I know work:
>
>1.  Silence individual devices,
>2.  Mask interrupts in the 8259,
>3.  Delay sending EOIs till the interrupt is handled in the device task.

I tend to favor #2 or #3 because I don't know how to silence the Ethernet
card.  With some effort, I can probably think of many more devices I don't
know how to silence.

>For methods 2 and 3 to work well, I think we have to look at setting the
>8259 into Special Mask Mode (SSM).  Normally, acknowledging an interrupt
>or masking an interrupt means that all lower level interrupts are masked
>as well.  In SSM, just the level being serviced or masked in inhibited;

I am nervous about this.  The bios_wini.c seems to work almost everywhere,
so I'd like to make this part of the standard boot diskette.  That way it
could boot on any machine.  People could then compile and install xx_wini.c
is they wanted to get the extra performance.  If we change the 8259A mode,
the BIOS may get all confused.  Furthermore, they may be other devices
that don't like messing around with the 8259A.  That is a very central
chip to the whole I/O system, so I am hesitant to reprogram it until I
fully understand the repercussions of doing so.  Still, if anyone
wants to try it and report back what happens, that could be a start.

One thing that still confuses me is why Al Crew (and now David Dyck)
report being able to boot my kernel on the PS/2 Model 50.  What my kernel
does is disable floppy interrupts in mpx88.s by twiddling bits in the
8259A.  In interrupt(), I changed the code to 

    if (task != FLOPPY) port_enable(INT_CTL, ENABLE) /* re-enable 8259A */

In floppy.c, I re-enable the 8259A floppy bit after sensing the FDC.
In effect this is solutions 2 and 3 above.  However, it is only for the
floppy!  Everything else works the way it always did.  Why don't we get
infinite clock interrupts etc?  Is the floppy the only level-triggered
device?  Do the other devices negate their levels automatically?  Strange.

Andy Tanenbaum (ast@cs.vu.nl)