Subject: Re: Console polling programming interface change (proposal)
To: None <eeh@netbsd.org, jdolecek@netbsd.org>
From: None <eeh@netbsd.org>
List: tech-kern
Date: 07/20/2001 18:16:31
| eeh@netbsd.org wrote:
| > Or, to be more precise, what other solutions have you examined and why
| > have they failed?
|
| The problem I have is that the IBM PS/2 keyboard controller seems to not drop
| the interrupt condition when the intr handler is invoked, and the intr
| handler is called endlessly. Thus, in order to ensure this would work
| also once interrupts are enabled late in boot, I need to raise spl level
| in cnpollc(1).
|
| I have tried to disable pckbc interrupts by frobbing some kbc
| mode bits. That didn't help. I think it's possible to clear the interrupt
| condition via some i386-specific way, but such functionality 
| is not exported to MI kernel. I though about some specific hacks to handle
| this by reading the keypress in pckbcintr and exporting it to
| cngetc somehow, but that seemed even more quirky. Thus, I ended up
| with this console polling interface change, which would make it
| possible for me to implement such quirk. 

I'm still trying to fully understand the problem.

Which specific drivers are involved?  Which cnpollc() and cngetc()
routines are called?

Which interrupt routines are being triggered?  

Is there no way to block the interrupt in that driver?  

Is there no way to acknowledge the interrupt without reading the 
input byte(s)?  

Why do you consider fixing this in the driver by passing the byte 
from the interrupt handler to the getc routine uglier than changing 
all MI code that usess cnpollc()?

Eduardo