All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Hurley <peter@hurleysoftware.com>
To: "Bollinger, Seth" <Seth.Bollinger@digi.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	linux-serial <linux-serial@vger.kernel.org>
Subject: Re: Possible software flow problem in serial_core
Date: Thu, 20 Mar 2014 19:05:35 -0400	[thread overview]
Message-ID: <532B743F.2030705@hurleysoftware.com> (raw)
In-Reply-To: <CF505B08.6E64%seth.bollinger@digi.com>

[ +cc linux-serial ]

On 03/20/2014 09:44 AM, Bollinger, Seth wrote:
> Hello All,
>
> We’ve recently run into a possible problem with software flow control
> handling in the serial_core layer.
>
> Here is the scenario:
>
> 1. Transmit from uart to remote device
> 2. Remote device sends us an XOFF
> 3. The tty layer receives the XOFF
> 4. stop_tty() - The uart transmitter is stopped (ops->stop_tx) just as the
> serial_core ring is cleared (this could trap a few bytes in the fifo).
> 5. Remote device sends us an XON
> 6. The tty layer receives the XON
> 7. start_tty() - However, the serial_core ring is empty, so the call to
> start the uart transmitter (uart_start:ops->start_tx) is skipped
>
> Any window, however small, could leave bytes stuck in the transmitter
> forever -- particularly if there will be no further transmission until
> receiving a response.
>
> I can't find any functionality in the drivers that accounts for this
> possibility.  Can you help me find how Linux serial drivers manage this
> eventuality?
>
> Thanks,
>
> Seth

What hardware is this?

A 16550 transmitter doesn't shut-off at uart->stop_tx(), so the remaining
data in the transmitter FIFO is still transmitted.

Some hardware has (relatively) big FIFOs and allows the transmitter to be
shutoff, but these should unconditionally re-enable the transmitter without
clearing the xmit fifo.

Are you seeing lost data? Maybe it's because soft flow-control is to
slow to shutoff the sender?

Regards,
Peter Hurley



WARNING: multiple messages have this Message-ID (diff)
From: Peter Hurley <peter@hurleysoftware.com>
To: "Bollinger, Seth" <Seth.Bollinger@digi.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	linux-serial <linux-serial@vger.kernel.org>
Subject: Re: Possible software flow problem in serial_core
Date: Thu, 20 Mar 2014 19:05:35 -0400	[thread overview]
Message-ID: <532B743F.2030705@hurleysoftware.com> (raw)
In-Reply-To: <CF505B08.6E64%seth.bollinger@digi.com>

[ +cc linux-serial ]

On 03/20/2014 09:44 AM, Bollinger, Seth wrote:
> Hello All,
>
> We’ve recently run into a possible problem with software flow control
> handling in the serial_core layer.
>
> Here is the scenario:
>
> 1. Transmit from uart to remote device
> 2. Remote device sends us an XOFF
> 3. The tty layer receives the XOFF
> 4. stop_tty() - The uart transmitter is stopped (ops->stop_tx) just as the
> serial_core ring is cleared (this could trap a few bytes in the fifo).
> 5. Remote device sends us an XON
> 6. The tty layer receives the XON
> 7. start_tty() - However, the serial_core ring is empty, so the call to
> start the uart transmitter (uart_start:ops->start_tx) is skipped
>
> Any window, however small, could leave bytes stuck in the transmitter
> forever -- particularly if there will be no further transmission until
> receiving a response.
>
> I can't find any functionality in the drivers that accounts for this
> possibility.  Can you help me find how Linux serial drivers manage this
> eventuality?
>
> Thanks,
>
> Seth

What hardware is this?

A 16550 transmitter doesn't shut-off at uart->stop_tx(), so the remaining
data in the transmitter FIFO is still transmitted.

Some hardware has (relatively) big FIFOs and allows the transmitter to be
shutoff, but these should unconditionally re-enable the transmitter without
clearing the xmit fifo.

Are you seeing lost data? Maybe it's because soft flow-control is to
slow to shutoff the sender?

Regards,
Peter Hurley


--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2014-03-20 23:05 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-20 13:44 Possible software flow problem in serial_core Bollinger, Seth
2014-03-20 23:05 ` Peter Hurley [this message]
2014-03-20 23:05   ` Peter Hurley
2014-03-20 23:34   ` Bollinger, Seth
2014-03-20 23:34     ` Bollinger, Seth
2014-03-21  0:34     ` Peter Hurley
2014-03-21  0:48       ` Bollinger, Seth
2014-03-21  1:07         ` Peter Hurley

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=532B743F.2030705@hurleysoftware.com \
    --to=peter@hurleysoftware.com \
    --cc=Seth.Bollinger@digi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    /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.