Subject: Re: Multipul screens
To: Jason Thorpe <thorpej@nas.nasa.gov>
From: michael smith <mike@smith.net.au>
List: port-hp300
Date: 06/01/1997 17:29:16
Jason Thorpe stands accused of saying:
>
> > 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...

Um.  Without the sources in front of me, I can't check whether
that matches the symptoms I'm seeing.  Does itestart just start
the ite output, or does it run any/all pending updates? 

>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.

Hmm. I didn't change anything particular there, as I wasn't 
expecting there to be any ite state that keyboard input
could change that might conflict with output.  The keyboard
interrupt handler is non-reentrant for a given keyboard,
which matches with a given ite.

The symptoms I'm seeing are consistent with interrupts on the
dca being suspended for the duration of the screen scroll/output;
I was expecting there to be an spltty() in there somewhere,
but I should have looked 8)

>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.

Is there any advantage to this?  There is no ite state that's modified
(currently) by the keyboard driver; it just translates codes and
shoves the resulting characters straight up into the console
tty, which has its own timeout handler running just below spltty().

(Again, I haven't seen your proposed changes, so I'm going
on what I did originally...)

>significantly.  You want to see a message near the bottom of the device
>messages like this:
>
>interrupt levels: bio = 3, net = 4, tty = 5

This comment belongs on the hp300 web page/FAQ 8)

>Jason R. Thorpe                                       thorpej@nas.nasa.gov

--
Mike Smith  *BSD hack  Unix hardware collector
The question "why are the fundamental laws of nature mathematical"
invites the trivial response "because we define as fundamental those
laws which are mathematical".  Paul Davies, _The_Mind_of_God_