public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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


  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox