On Wed, 2013-03-06 at 19:17 +0530, Vineet Gupta wrote: > Hi, > > I'm seeing truncated serial console output, with 3.8 based arc_uart driver > (drivers/tty/serial/arc_uart.c) <...snip...> > 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. Hi Vineet, You're correct in that this is not driver related, and that it's a problem in the tty core, specifically in __tty_hangup(). The problem is actually worse with a really high speed tty (like over Firewire) and on the receive end can amount to 60+K of dropped data. The problem stems from the semantics of 'hangup': for one usage, it means 'this end is done transmitting' and in the other usage, it means 'don't send me anymore data'. So for first meaning, receiving all the data is important. In the second meaning, the receiver doesn't want data anymore. Unfortunately, there is almost no distinction in the tty core; it implements the second meaning while providing interface for the first meaning. I'm meaning to address this eventually (because I'm working around this now in TTY-over-Firewire -- its on the receive end so wouldn't be any help in your situation), but don't have a plan on how to best fix this yet. Regards, Peter Hurley -- 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
