LKML Archive mirror
 help / color / mirror / Atom feed
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: Fri, 5 Feb 2016 01:19:44 +0200	[thread overview]
Message-ID: <CAHp75VfLDbOuLAfaNK8OuZyS4AR3tJUTUC2TNx+HbmEV_zbcZQ@mail.gmail.com> (raw)
In-Reply-To: <20160204231528.GI10826@n2100.arm.linux.org.uk>

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).


> --
> RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.



-- 
With Best Regards,
Andy Shevchenko

  reply	other threads:[~2016-02-04 23:19 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 [this message]
2016-02-05  1:09     ` Russell King - ARM Linux
2016-02-08  8:51       ` Andy Shevchenko

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=CAHp75VfLDbOuLAfaNK8OuZyS4AR3tJUTUC2TNx+HbmEV_zbcZQ@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).