From: Andy Shevchenko <andy.shevchenko@gmail.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Peter Hurley <peter@hurleysoftware.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>
Subject: Re: Data corruption on serial interface under load
Date: Mon, 8 Feb 2016 10:51:26 +0200 [thread overview]
Message-ID: <CAHp75VeHUWjPSYPpoWiR0E54fscEj4CSqJU4V9SrTwLcXaRmJQ@mail.gmail.com> (raw)
In-Reply-To: <20160205010906.GK10826@n2100.arm.linux.org.uk>
On Fri, Feb 5, 2016 at 3:09 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Feb 05, 2016 at 01:19:44AM +0200, Andy Shevchenko wrote:
>> On Fri, Feb 5, 2016 at 1:15 AM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Thu, Feb 04, 2016 at 08:55:48PM +0200, Andy Shevchenko wrote:
>> >> Hi!
>> >>
>> >> Today I observed interesting bug / feature of uart layer in the kernel.
>> >> I do have a setup which connects two identical devices by serial line.
>> >> I run data transferring in one direction and got data corruption on
>> >> receiver side (in uart layer, not the driver).
>> >>
>> >> Here is the dump from test suite and real data from 8250 registers:
>> >>
>> >> === 8< ===
>> >>
>> >> Needed 16 reads 0 writes Oh oh, inconsistency at pos 1 (0x1).
>> >>
>> >> Original sample:
>> >> 00000000: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 .ELF............
>> >> 00000010: 02 00 03 00 01 00 00 00 19 8d 04 08 34 00 00 00 ............4...
>> >> 00000020: 2c f2 00 00 00 00 00 00 34 00 20 00 04 00 28 00 ,.......4. ...(.
>> >>
>> >> Received sample:
>> >> 00000000: 7f 00 45 00 4c 00 46 00 01 00 01 00 01 00 00 00 ..E.L.F.........
>> >> 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> >> 00000020: 02 00 00 00 03 00 00 00 01 00 00 00 00 19 8d 04 ................
>> >> loops 1 / 1
>> >>
>> >> cts: 0 dsr: 0 rng: 0 dcd: 0 rx: 53434 tx: 0 frame 0 ovr 34201 par: 0
>> >> brk: 0 buf_ovrr: 0
>> >>
>> >> === 8< ===
>> >>
>> >> R 356.360109 IIR 0xc4
>> >> R 356.360114 LSR 0x63
>> >> R 356.360119 RX 0x7f
>> >
>> > I think the obvious question here is: why is your serial port reporting
>> > overrun errors in loopback mode.
>> >
>> > If you have no flow control, I suspect this is likely to happen: if we
>> > try to fill the Tx FIFO, we won't be servicing the port trying to receive
>> > characters.
>> >
>> > So if (eg) the port already contains 12 characters in the RX FIFO, and
>> > we load up a full complement of characters into the TX FIFO, the port
>> > will transmit them to the RX side. As we will not be reading the RX
>> > side (as we're busy loading the TX side), if we fill the RX FIFO, you'll
>> > then get overruns.
>> >
>> > Even so, with a dumb 8250 based UART, there's no hardware assisted flow
>> > control, so it's never going to be particularly reliable. More modern
>> > UARTs have realised this, and have implemented hardware (and software)
>> > flow control mechanisms in hardware to reduce the chances of overruns.
>> >
>>
>> Yeah, above makes sense to me, but that is another issue I'm
>> investigating. The issue I complained about is additional '\0'
>> characters (seems uart_insert_char() does this).
>
> Firstly, let's establish why this happens. When an overflow error occurs,
> what has happened is that a character was received by the hardware which
> it had no room in its receive FIFO, and so the character is discarded.
> However, the UART records that act in a flag.
>
> Sensible ports attach the flag to the preceding character so that software
> can read the successfully received characters without needing to care for
> the overflow.
>
> The Linux behaviour on encountering an overflow condition is to "undo"
> the discarding: a NUL character is inserted into the stream which is
> marked with a TTY_OVERRUN status. (Standard Linux behaviour is to mark
> the in-error characters with their error status if they are to be
> received.)
>
> When in-band error reporting to the application is disabled, this appears
> as a plain NUL character.
>
> I think the issue here is "if they are to be received". If you have
> cleared IGNBRK, break characters will be reported as NUL character. If
> IGNPAR is clear, a character with incorrect parity could be reported to
> the application as a NUL character (it depends on other settings.)
>
> Overflow is not covered in the standard termios modes, and it's been
> standard Linux behaviour to pass these through unless both IGNPAR and
> IGNBRK are set.
>
> cfmakeraw clears IGNPAR, which means it's not in "real raw" mode. If
> you want to ignore parity, break, framing and overflow errors in the
> resulting byte stream, you need to ensure IGNPAR and IGNBRK are both
> set.
Thank you for such a detailed explanation!
--
With Best Regards,
Andy Shevchenko
prev parent reply other threads:[~2016-02-08 8:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-04 18:55 Data corruption on serial interface under load Andy Shevchenko
2016-02-04 20:06 ` Peter Hurley
2016-02-04 22:24 ` Andy Shevchenko
2016-02-04 22:27 ` Andy Shevchenko
2016-02-04 23:16 ` Russell King - ARM Linux
2016-02-04 23:15 ` Russell King - ARM Linux
2016-02-04 23:19 ` Andy Shevchenko
2016-02-05 1:09 ` Russell King - ARM Linux
2016-02-08 8:51 ` Andy Shevchenko [this message]
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=CAHp75VeHUWjPSYPpoWiR0E54fscEj4CSqJU4V9SrTwLcXaRmJQ@mail.gmail.com \
--to=andy.shevchenko@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=peter@hurleysoftware.com \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).