From: "Roland Caßebohm" <roland.cassebohm@VisionSystems.de>
To: linux-kernel@vger.kernel.org
Cc: Paul Fulghum <paulkf@microgate.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Russell King <rmk+lkml@arm.linux.org.uk>
Subject: Re: Serial driver hangs
Date: Fri, 1 Oct 2004 17:22:28 +0200 [thread overview]
Message-ID: <200410011722.28877.roland.cassebohm@visionsystems.de> (raw)
In-Reply-To: <1096579503.1938.166.camel@deimos.microgate.com>
Am Donnerstag, 30. September 2004 23:25 schrieb Paul Fulghum:
> On Thu, 2004-09-30 at 15:10, Alan Cox wrote:
> > On Iau, 2004-09-30 at 21:30, Paul Fulghum wrote:
> > > tty->flip.work.func and tty->flip.tqueue.routine
> > > are set to flush_to_ldisc()
> >
> > flush_to_ldisc was ok, then someone added the low latency
> > flag. In the current 2.6.9rc3 patch flush_to_ldisc
> > honours TTY_DONT_FLIP also
>
> In the cases I described the low latency flag
> does not come into play because flush_to_ldisc()
> is called directly instead of
> through tty_flip_buffer_push().
>
> TTY_DONT_FLIP is only set in read_chan().
> If read_chan() is not running, TTY_DONT_FLIP is not
> set and does not prevent buffers from flipping
> if the ISR calls flush_to_ldisc() directly
> while ldisc->receive_buf() is running.
>
> The answer seems to be: don't call
> flush_to_ldisc directly like the current
> serial driver does.
Yes, I think you are right, if the system is to slow to fetch
the data fast enough the buffer will be sometime full. And if
it would be possible to use the second flip buffer then, this
buffer would be full too sometime.
It would just take a little longer till data got lost. But if
I want that I could just make the buffers larger.
...
I have just tested it, but unfortunately I've got a very bad
result. :-( In my test case (2 port with 921600 baud) I get
very much data loss.
I think I will stay now by the solution of just trow away the
characters from the FIFO if flip buffer is full and
TTY_DONT_FLIP is set. I will test now the patch Paul has
made.
Roland
next prev parent reply other threads:[~2004-10-01 15:22 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-28 15:34 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
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 [this message]
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=200410011722.28877.roland.cassebohm@visionsystems.de \
--to=roland.cassebohm@visionsystems.de \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=paulkf@microgate.com \
--cc=rmk+lkml@arm.linux.org.uk \
/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
Powered by JetHome