From: Peter Hurley <peter@hurleysoftware.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Russell King <linux@arm.linux.org.uk>,
"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: Thu, 4 Feb 2016 12:06:44 -0800 [thread overview]
Message-ID: <56B3AF54.2050609@hurleysoftware.com> (raw)
In-Reply-To: <CAHp75VehshCyAjKiOyB26zkeu4WUar9-z-XfFNLuchc0swyvSQ@mail.gmail.com>
Hi Andy,
On 02/04/2016 10:55 AM, 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 RDI interrupt
> R 356.360114 LSR 0x63 DR + OE
> R 356.360119 RX 0x7f
> R 356.360124 LSR 0x63 DR + still OE
> R 356.360128 RX 0x45
> R 356.360133 LSR 0x63 DR + still OE
> R 356.360137 RX 0x4c
> R 356.360142 LSR 0x63 DR + still OE
> R 356.360147 RX 0x46
> R 356.360151 LSR 0x63 DR + still OE
> R 356.360156 RX 0x01
> R 356.360160 LSR 0x63 DR + still OE
> R 356.360165 RX 0x01
> R 356.360169 LSR 0x63
> R 356.360174 RX 0x01
>
> As we can see the data is corrupted on Linux side. Can we somehow fix
> this bug/feature?
Not quite sure what you see as the issue.
1) That is a lot of overruns. Is that part of the test or are the overruns
a regression?
2) If you mean the NUL bytes for overruns, I could have some functional mode
mis-branched in the N_TTY line discipline. What are the termios settings
on the rx side?
Regards,
Peter Hurley
next prev parent reply other threads:[~2016-02-04 20:06 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 [this message]
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
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=56B3AF54.2050609@hurleysoftware.com \
--to=peter@hurleysoftware.com \
--cc=andy.shevchenko@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=linux@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).