All of lore.kernel.org
 help / color / mirror / Atom feed
From: linux@bohmer.net (Remy Bohmer)
To: linux-arm-kernel@lists.infradead.org
Subject: at91: input overruns question
Date: Sun, 31 Oct 2010 12:19:38 +0100	[thread overview]
Message-ID: <AANLkTi=AhMxUjN=0PfW+XKVDJBhok=f4YwpF6bf67Eza@mail.gmail.com> (raw)
In-Reply-To: <AANLkTimHnxLydJC3u58kAuukjR80EEgRDj7ZEedNMKfd@mail.gmail.com>

Hi,

2010/10/28 Aras Vaichas <arasv@magellan-technology.com>:
> On 26 October 2010 17:19, Aras Vaichas <arasv@magellan-technology.com> wrote:
>> Hi,
>>
>> I'm updating our production kernel to 2.6.33.7-rt29 for an at91rm9200.
>> This is the newest version supported by RT.
>>
>> I've noticed that the age-old debug serial input overrun(s) issue has
>> gotten far worse and I can no longer use the cursor keys at all. i.e.
>> no history on serial console or vi.
>>
>> As the kernel version numbers have gone up, the problem seems to have
>> gotten worse.
>>
>> Is there anything that I can do to make it a bit more usable?
>>
>> Any .config changes?
>
> Configuration settings CONFIG_NO_HZ and CONFIG_HIGH_RES_TIMERS cause
> the overrun(s) problems to get worse.

Indeed. high-res timers and no-hz have a longer interrupt handling
compared to the old fashioned ticking kernel.

> If I disable these two settings I still get overrun(s) but not quite
> as frequent.

> Can someone explain why these settings would cause the CPU to be
> unable to process 2 serial characters in a row?
> Something must be causing the DBGU serial receive interrupt to stall
> for more than 86us in order to miss a complete 115200 baud serial
> character.

The DBGU has a 1 byte FIFO, thus not a FIFO at all. As you already
mention, the time between 2 interrupts on 115200 baud must be about
86us. On rm9200 the timer interrupt handler itself can cost about 50us
to more than 100usec in itself (measured through ETM
trace), combined with a worst case interrupt latency of about 75us.
This is even worse on a HRT or NOHZ enabled kernel.
So, mathematically you can already prove that it cannot keep up to the
115200 properly.

Enabling DMA for DBGU is no option either since IIRC it would only
generate an interrupt once the DMA buffer is full, not when the first
character arrives in the buffer. Thus not very useful for a terminal.

See for more info about the timer interrupt:
http://linux.derkeiler.com/Mailing-Lists/Kernel/2008-03/msg01954.html
and
http://linux.derkeiler.com/Mailing-Lists/Kernel/2008-03/pnga98YRFl9x7.png
(ETM trace screendump of the timer interrupt handler)

Kind regards,

Remy

  reply	other threads:[~2010-10-31 11:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-26  6:19 at91: input overruns question Aras Vaichas
2010-10-26  6:49 ` Uwe Kleine-König
2010-10-27  1:00   ` Aras Vaichas
2010-10-28  3:14 ` Aras Vaichas
2010-10-31 11:19   ` Remy Bohmer [this message]
2010-11-01 23:33     ` Aras Vaichas
2010-11-02 14:11       ` Remy Bohmer

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='AANLkTi=AhMxUjN=0PfW+XKVDJBhok=f4YwpF6bf67Eza@mail.gmail.com' \
    --to=linux@bohmer.net \
    --cc=linux-arm-kernel@lists.infradead.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.