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
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
