I've pondered the following for a few days;  corrections/additions much 
appreciated....

In theory, I beleive I may have solved the PS/2 mouse interrupt handling 
problems I've been having, by adding

   #define ICU_SPECIAL_MASK_MODE

at the top of <arch/i386/isa/vector.s>.

What that mainly does, is change where the EOI (end of interrupt) is issued.

By default -- with ICU_HARDWARE_MASK -- the IRQ handler masks the IRQ, then 
issues the EOI, then decides whether to call the driver handler or block it 
(based on the spl).  If it blocks, because the EOI was already issued, the
hardware that triggered the IRQ can go ahead and do more I/O while the driver 
handler is blocked.  If the hardware then gets input that overwrites the input 
that caused the IRQ, when the driver handler runs it will handle the newer 
input, not the the input it was supposed to handle.

With ICU_SPECIAL_MASK_MODE, the EOI is never issued until after the driver 
handler has actually run, whether blocked or not.  The driver therefore always 
handles the correct data.


Notes:
------

This PS/2 mouse controller is in the keyboard controller, and yes, I _have_ 
had
(even rarer) problems with the keyboard locking up, if I type a certain key 
sequence too quickly.

The motherboard at issue uses the VIA Apollo MVP3 chipset, which integrates 
the keyboard controller into the 586B south bridge chip.  Intel chipsets seem 
to leave the keyboard controller to an external chip, so there might be a 
difference in the clock rate at which the controller interacts with the 
chipset and the CPU -- including IRQ handling.  Such a difference (perhaps as 
wide as 100 MHz vs 8 MHz) might explain why I see a problem where others don't.

Does this discussion apply to the IDE driver's "lost interrupt" problem?  IDE 
controllers _are_ typically integrated into the chipset.  Does the IDE driver 
handler depend on the data to catch the interrupt?  I can't bear to look.

Finally, my PS/2 mouse problems have always been very hard to reproduce on 
demand, so I may never be absolutely certain of the cause(s) or solution(s).  
How do you prove a negative, it's like nailing jelly to a wall, etc, etc.


--Jim Howard  <jiho@mail.c-zone.net>