On Sun, 01 Jun 1997 16:06:06 +0930 (CST) 
 michael smith <mike@smith.net.au> wrote:

 > Just a heads-up, while you're integrating the driver make sure to
 > add a keymap entry for ^], which I completely forgot.  It makes
 > using telnet on the console very difficult.

Ok... if I have a question about it, I'll drop you a note.

 > Also, and speaking of _major_ console gripes, is it possible to
 > have the ite and the framebuffer drivers run at a lower spl?  If
 > you desire an understanding of the current problem, try this :

All of ite.c runs at low spl _except_ itestart, which protects
all manipulation of the tty with an splkbd(), since the keyboard
is the only thing that can affect it's state...

Now, in current, stock kernels, splkbd() == splhil() == spl1().  That
blocks no serial interrupts.  When using the Domain keyboard, however,
splkbd() would either have to be dynamically computed or replaced
with a call to spltty(), because the Domain keyboard is attached to
a serial port which interrupts at level 5, the highest level of
any device except for the clock... However, I don't see a change
to that call in your ite diffs, nor do I see a change to the
definition of splkbd().  I can only assume you made that change,
however, because that is the only thing that would cause the
ite to block serial interrupts.

Thankfully, I have already thought about this, and have a plan :-)

splkbd() will be changed to expand to spl1() (which is what it currently
expands to anyhow :-), but the comment will change:

/*
 * This is the same level as splhil() and the level the soft interrupt
 * routines run at.
 */
#define	splkbd()	spl1()

The Domain keyboard driver will be altered slightly... the hardware
interrupt routine will simply fill a ring buffer, and schedule a
software interrupt.  The next time spl drops low enough (which happens
to be just below splkbd() :-), the dnkbd soft interrupt routine will
run, and feed characters to the ite.

 > It's also interesting that there are no console messages about the
 > overflows, although I think this is a 'feature' of the driver.

Of the DCA driver, yes... I plan on fixing that.  On the DCM driver,
the one I use for my ppp link, the messages are printed:

dcm0 port 0: silo overflow

...although I get almost none (that one is the only one in ... 8 days
of _heavy_ use of my link, and it happened while I was starting X,
I think) since I redid the interrupt code (again) a few (several?)
months ago to dynamically compute interrupt levels for various spl
calls ... then, setting my scsi and hpib devices to ipl 3, LAN cards
to ipl 4, and serial devices to ipl 5 (all with either the 345/375/380/4xx
configuration EEPROM or switches/jumpers on the cards/mainboards)
magically made the heirarchy such that heavy disk activity or heavy LAN
activity never blocks serial interrupts.  If people haven't done this
already, I _strongly_ recommend it, as it improves serial performance
significantly.  You want to see a message near the bottom of the device
messages like this:

interrupt levels: bio = 3, net = 4, tty = 5

...and sometime down the road, I plan on _COMPLETELY_ rototilling the
serial drivers in the hp300 port.  But I'm not going to make any timeline
promises :-)

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                               Home: 408.866.1912
NAS: M/S 258-6                                          Work: 415.604.0935
Moffett Field, CA 94035                                Pager: 415.428.6939