Re: TTY loosing bytes ?

[Felipe Balbi <felipe.balbi@nokia.com>]

On Tue, Oct 06, 2009 at 03:11:15PM +0200, ext Alan Cox wrote:
> > With the patch above I still get this messages but it still goes through
> > since not receive_buf is returning the amount of bytes actually
> > received. Then flush_to_ldisc() will retry those bytes on the next
> > iteration. Maybe this is not the desired patch though ?
> > 
> > Thanks a lot for the comments Alan.
> 
> First guess try the following
> 
> n_tty: For some I/O patterns n_tty will lose bytes
> 
> From: Alan Cox <alan@linux.intel.com>
> 
> Fix the obvious disagreement between the receive path and the receive room
> logic.
> 
> Signed-off-by: Alan Cox <alan@linux.intel.com>
> ---
> 
>  drivers/char/n_tty.c |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> 
> diff --git a/drivers/char/n_tty.c b/drivers/char/n_tty.c
> index 2e50f4d..27b28ca 100644
> --- a/drivers/char/n_tty.c
> +++ b/drivers/char/n_tty.c
> @@ -95,6 +95,9 @@ static void n_tty_set_room(struct tty_struct *tty)
>  	/* tty->read_cnt is not read locked ? */
>  	int	left = N_TTY_BUF_SIZE - tty->read_cnt - 1;
>  
> +	if (tty->real_raw)
> +	        left = min(left, N_TTY_BUF_SIZE - tty->read_head - 1);
> +
>  	/*
>  	 * If we are doing input canonicalization, and there are no
>  	 * pending newlines, let characters through without limit, so

unfortunately it didn't work. Although now I don't the debugging prints
complaining we've lost bytes, the transfer does get stuck in lot earlier
stage.

Maybe this is one fix but there's still other problem with that code ?

-- 
balbi