public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Raphael Hertzog <hertzog@debian.org>
To: Linux Kernel ML <linux-kernel@vger.kernel.org>
Subject: How to avoid serial port buffer overruns?
Date: Wed, 16 Aug 2006 12:45:59 +0200	[thread overview]
Message-ID: <20060816104559.GF4325@ouaza.com> (raw)

(Please CC me when replying)

Hello,

While using Linux on low-end (semi-embedded) hardware (386 SX 40Mhz, 8Mb
RAM), I discovered that Linux on that machine would suffer from serial
port buffer overruns quite easily if I use a baudrate high enough (I start
loosing bytes at >19200 bauds and I would like to make it reliable up to 
115 kbauds). I check if overruns are happening with
/proc/tty/driver/serial ("oe" field).

Back when I was using the 2.4 kernel, I reduced dramatically the frequency
of overruns by using the "low latency" and "preemptible kernel" patch [1]. But
it still happened sometimes at 115 kbauds if the system was a bit loaded
(with disk I/O for example).

Now I switched to stock 2.6 and while the stock kernel improved in
responsiveness, it still isn't enough by default (even with
CONFIG_PREEMPT=y and CONFIG_HZ=1000). So I wanted to try the "rt" patch of
Ingo Molnar and Thomas Gleixner, but the patched kernel doesn't boot (see
bug report in a separate mail on this list).

Other things that I tried which didn't help (enough) are:

- tuning with hdparm
  - make disk IRQ interruptible with hdparm -u 1 /dev/hda
  - activating DMA is suggested but my disk is a "disk on module"
    and doesn't support DMA
- using irqtune (http://cae.best.vwh.net/irqtune/) to reprioritize
  interrupts
  irqtune is old and it's very difficult to know if it still works
  reliably with recent kernel and as there's no way to "read" the
  interrupt priorities, I have no way to know if irqtune changed anything
  at all...

My questions are thus:
1/ Is there a way to patch the kernel to make it handle serial IRQ as
   the highest priority? If yes, how? Where should I look at to create
   such a patch?
2/ How can I identify why the serial interrupts are delayed? Or, in other
   words, how can I find the code blocking for too long the treatment of
   the serial IRQ?
   I suppose that network IRQ and disk IRQ are responsible for that but
   I'm not sure and furthermore disk interrupts are supposed to
   be interruptible given the hdparm config that I use.
3/ What other suggestions do you have to avoid those serial buffer
   overruns?

As usual, I'll gladly try out patches/ideas and will provide any
required additional information that I didn't include in this mail.

Some infos on the hardware:
http://www.icop.com.tw/products_detail.asp?ProductID=205
More detailed spec of the CPU are here:
http://www.dmp.com.tw/tech/m6117d/

bash-2.05a# cat /proc/interrupts
CPU0
0:   88503366          XT-PIC  timer
2:          0          XT-PIC  cascade
3:         11          XT-PIC  serial
4:         12          XT-PIC  serial
5:       4958          XT-PIC  NE2000
14:      10771          XT-PIC  ide0
NMI:          0
ERR:          0

Regards,

[1] I documented that in a blog post last year:
http://www.ouaza.com/wordpress/2005/10/19/serial-overrun-on-linux/
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/

             reply	other threads:[~2006-08-16 10:46 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-16 10:45 Raphael Hertzog [this message]
2006-08-16 14:31 ` How to avoid serial port buffer overruns? Lennart Sorensen
2006-08-16 14:57   ` Raphael Hertzog
2006-08-16 18:44 ` Lee Revell
2006-08-16 19:23   ` Paul Fulghum
2006-08-16 21:12     ` Lee Revell
2006-08-16 22:24       ` Paul Fulghum
2006-08-16 23:10         ` Russell King
2006-08-16 23:15           ` Lee Revell
2006-08-16 23:19             ` Russell King
2006-08-16 23:28               ` Lee Revell
2006-08-17  0:15                 ` R: " Giampaolo Tomassoni
2006-08-18  8:48                 ` Giampaolo Tomassoni
2006-08-18 17:00                   ` Lee Revell
2006-08-18 17:04                     ` Russell King
2006-08-18 17:30                       ` Lee Revell
2006-08-18 18:34                         ` Russell King
2006-08-18 18:52                           ` Lee Revell
2006-08-18 19:01                             ` Russell King
2006-08-18 19:07                               ` Russell King
2006-08-18 19:09                               ` Lee Revell
2006-08-17  9:20           ` Alan Cox
2006-08-17  9:28             ` Russell King
2006-08-17 11:57               ` Alan Cox
2006-08-17 13:29                 ` Paul Fulghum
2006-08-17 15:48                 ` Raphael Hertzog
2006-08-17 16:10         ` Raphael Hertzog
2006-08-17 16:40           ` Paul Fulghum
2006-08-18 19:31           ` Lee Revell
2006-08-23 12:45             ` Raphael Hertzog
     [not found] <fa.AByCsBI8k71hMVzCyQVimrLiDU4@ifi.uio.no>
2006-08-16 14:35 ` Robert Hancock
2006-08-16 14:42   ` Erik Mouw

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=20060816104559.GF4325@ouaza.com \
    --to=hertzog@debian.org \
    --cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox