From: Vineet Gupta <Vineet.Gupta1@synopsys.com>
To: linux-serial@vger.kernel.org
Cc: Jiri Slaby <jslaby@suse.cz>
Subject: arc_uart: serial output truncated
Date: Wed, 6 Mar 2013 19:17:22 +0530 [thread overview]
Message-ID: <513748EA.7050407@synopsys.com> (raw)
Hi,
I'm seeing truncated serial console output, with 3.8 based arc_uart driver
(drivers/tty/serial/arc_uart.c)
It would seem funny that I'm the driver author and still bringing this up -
because this seems like an interplay of tty-core/serial-core with a slow serial
device, rather than a driver specific issue, which is causing this.
The basic call flow is a write(2) to STDERR which lands in the tty layer. The
routine n_tty_write() successfully copies the complete msg from tty layer's buffer
to driver's tx buffer (tty->driver_state->xmit->buf). There are 3 arc-uart driver
output calls in that codepath and with 1 deep Tx FIFO only 3 characters are output
- as follows:
n_tty_write
process_output_block
tty->ops->write --> full user buffer
uart_write
copy tty buffer into driver buffer
uart_start
port->ops->start_tx
arc_serial_tx_chars ==> 1st char
process_output
tty->ops->write --> "\r\n"
uart_start
port->ops->start_tx
arc_serial_tx_chars ==> 2nd char
tty_flush_chars
uart_start
port->ops->start_tx
arc_serial_tx_chars ==> 3rd char
Once interrupts are re-enabled (spin_unlock_irqrestore) a few more chars are
output via the driver ISR path.
However user app then immediately calls exit().
do_exit
tty_release
uart_close
tty_port_close_start --> returns 0 - because port->count == 4
...
disassociate_ctty
tty_ldisk_hangup
tty_driver_flush_buffer
tty->ops->flush_buffer
uart_flush_buffer
uart_circ_clear --> zeros the driver tx buffer head/tail
tty_port_close_start() has logic for port->drain_delay but in my case the
port->count is 4 (3 due to init task, 1 from this specific app) so that logic is
not hit.
Eventually, uart_flush_buffer is called, with unwritten data still present, but
the head/tail pointers are reset, causing that driver data to be effectively lost.
So maybe this is how it works (for a 1 deep FIFO uart) but I wanted to confirm
with the serial gurus. Is there any serial setting I can apply here to enable the
last remaining chars to be dumped out of uart tx buffer.
Thx,
-Vineet
next reply other threads:[~2013-03-06 13:47 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-06 13:47 Vineet Gupta [this message]
2013-03-06 18:58 ` arc_uart: serial output truncated Peter Hurley
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=513748EA.7050407@synopsys.com \
--to=vineet.gupta1@synopsys.com \
--cc=jslaby@suse.cz \
--cc=linux-serial@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 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.