hvc_console & interrupts: reworked patch

[Ryan Arnold]

Ben, Thanks for the clarifications.

On Tue, 2004-04-13 at 18:41, Benjamin Herrenschmidt wrote:

> > You obviously use it TTY throttle predictor anticipator.  The danger is
> > that when you push the data if you over estimated the amount of data you
> > could flip you just end up over writing the tty buffer.
> >
> > If you underestimated then the TTY will never throttle and you'll never
> > get the TTY unthrottle callback, hence no hvc_kick() to continue reading
> > data.
>
> How so ? I don't need kick to continue reading data on a non-throttled
> line. Just the interrupt or the 10ms timeout on non-interrupt setups.
> Or is there a bug ?

Well, I'm not sure if there is a bug or not but in my testing today I've
found that console input stops working after a few characters on a
Power-5 system.  I don't think this behavior is related to what I was
getting at in my earlier email but I'll investigate.  I should be able
to track down what is happening pretty easily.

My point earlier is that the hypervisor only sends a single interrupt
concerning available data until all the data is removed from the HV.
This int causes an hvc_kick() which wakes up the task running
hvc_poll().

If the hvc_poll() task is reading data and it predicts that our last HV
read and tty flip may have throttled the TTY the hvc_poll() function
calls yield() on the task and awaits a hvc_unthrottle call to hvc_kick()
and wake the task.

If we were wrong and the TTY wasn't throttled we won't receive an
unthrottle() callback, nor another data interrupt (since we never pulled
all the data), which means that the there won't be any further data read
until the system returns control to this thread due to the yield() and
its long sleeping nature.

Ryan S. Arnold
IBM Linux Technology Center


** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/