From: Paul Fulghum <paulkf@microgate.com>
To: "Roland Caßebohm" <roland.cassebohm@VisionSystems.de>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Russell King <rmk+lkml@arm.linux.org.uk>
Subject: Re: Serial driver hangs
Date: Thu, 30 Sep 2004 14:09:58 -0500 [thread overview]
Message-ID: <1096571398.1938.112.camel@deimos.microgate.com> (raw)
In-Reply-To: <200409301816.44649.roland.cassebohm@visionsystems.de>
On Thu, 2004-09-30 at 11:16, Roland Caßebohm wrote:
> Maybe I can use the functions rs_throttle() and
> rs_unthrottle(). In rs_unthrottle I could reenable the RX
> interrupt. So I don't need to add a function in "struct
> tty_driver". I only need to set the flag TTY_THROTTLED if I
> disable the interrupt.
The question is when to unthrottle:
Doing it in N_TTY read_chan() does not mean a
flip buffer is available.
Doing it in flush_to_ldisc() could unthrottle
when the ldisc receive buffer is still full.
It is a problem of using a single mechanism to
throttle the receiver in response to
two seperate triggers (flip buffer state and
ldisc receive buffer state).
> Maybe TTY_DONT_FLIP is really don't needed anymore.
The only use I see for TTY_DONT_FLIP is
delaying transfers of data from a flip buffer
to the N_TTY receive buffer via ldisc->receive_buf()
while N_TTY read_chan() is returning data
from the N_TTY receive buffer to the user app.
This behavior maximizes free space in the
N_TTY receive buffer before sending the next
flip buffer to ldisc->receive_buf().
N_TTY ldisc receive buffer access is
protected by tty->read_lock, so not using
TTY_DONT_FLIP wont corrupt this buffer.
However, if there is not enough room in the
N_TTY receive buffer when ldisc->receive_buf()
is called then data is lost.
> I think to be save and fast maybe one way could be, if the
> flip buffer is full it should be flipped but not processed
> with tty->ldisc.receive_buf() in the interrupt routine.
> flush_to_ldisc() has then always to look at both flip buffers
> and process them.
> If the second flip buffer is still not clean, if the interrupt
> routine needs to flip it, it has to stop the flow and disable
> the receive interrupt.
> unthrottle() could then reenable the interrupt.
The gaping hole in the flip buffer scheme is
flush_to_ldisc() can be called from hard IRQ
context while ldisc->receive_buf() is running.
This can flip buffers while ldisc->receive_buf() is
still reading from one of the flip buffers.
That corrupts data if the device ISR overwrites
the buffer before ldisc->receive_buf() finishes
reading from it.
A mechanism is required to prevent flipping
buffers while ldisc->receive_buf() is running.
TTY_DONT_FLIP would work, but is already in
use for the purpose described above :-)
I understand the plan is to eliminate or replace
the flip buffer scheme. I doubt patches tinkering
with the current scheme will be accepted.
--
Paul Fulghum
paulkf@microgate.com
next prev parent reply other threads:[~2004-09-30 19:15 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-28 15:34 Serial driver hangs Roland Caßebohm
2004-09-28 21:10 ` Paul Fulghum
2004-09-28 21:16 ` Russell King
2004-09-28 23:03 ` Paul Fulghum
2004-09-28 22:12 ` Alan Cox
2004-09-29 1:12 ` Paul Fulghum
2004-09-29 13:09 ` Roland Caßebohm
2004-09-29 13:17 ` Paul Fulghum
2004-09-29 14:07 ` Roland Caßebohm
2004-09-29 14:25 ` Paul Fulghum
2004-09-30 16:16 ` Roland Caßebohm
2004-09-30 19:09 ` Paul Fulghum [this message]
2004-09-30 18:34 ` Alan Cox
2004-09-30 19:51 ` Paul Fulghum
2004-09-30 19:59 ` Russell King
2004-09-30 20:05 ` Paul Fulghum
2004-09-30 20:30 ` Paul Fulghum
2004-09-30 20:10 ` Alan Cox
2004-09-30 21:25 ` Paul Fulghum
2004-10-01 0:47 ` Paul Fulghum
2004-10-01 15:22 ` Roland Caßebohm
2004-10-01 16:06 ` Paul Fulghum
2004-10-01 20:13 ` Stuart MacDonald
2004-10-01 20:36 ` Paul Fulghum
2004-09-29 14:13 ` Paul Fulghum
2004-10-01 15:25 ` Roland Caßebohm
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1096571398.1938.112.camel@deimos.microgate.com \
--to=paulkf@microgate.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=rmk+lkml@arm.linux.org.uk \
--cc=roland.cassebohm@VisionSystems.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.