Re: Strange problem with tty layer

[lsorense@csclub.uwaterloo.ca (Lennart Sorensen)]

On Thu, Jan 25, 2007 at 10:16:39AM -0500, Lennart Sorensen wrote:
> I am now trying this, which so far seem to help (I had a printk in there
> earlier and managed to trigger that).
> 
> --- ori/drivers/char/tty_io.c	2007-01-24 18:02:48.000000000 -0500
> +++ new/drivers/char/tty_io.c	2007-01-25 09:50:02.000000000 -0500
> @@ -2774,6 +2778,14 @@
>  	spin_lock_irqsave(&tty->buf.lock, flags);
>  	while((tbuf = tty->buf.head) != NULL) {
>  		while ((count = tbuf->commit - tbuf->read) != 0) {
> +			if (!tty->receive_room) {
> +				schedule_delayed_work(&tty->buf.work, 1);
> +				spin_unlock_irqrestore(&tty->buf.lock, flags);
> +				goto out;
> +			}
> +			if (count > tty->receive_room) {
> +				count = tty->receive_room;
> +			}
>  			char_buf = tbuf->char_buf_ptr + tbuf->read;
>  			flag_buf = tbuf->flag_buf_ptr + tbuf->read;
>  			tbuf->read += count;
> 
> This appeared to be (essentially) the key change in 2.6.18 related to
> the check of tty->receive_room.
> 
> I will now run a bunch more tests to see if it manages to keep it from
> having any more character losses.
> 
> Thank you for the suggestion of where to look.

Well it turns out that didn't help.  Neither does 2.6.18 (that one was
the easiest newer one to try).  It does seem as if the error rate is
lower with 2.6.18 than with 2.6.16, so perhaps there was more than one
place that could cause losses in the tty buffering.  I had only 2
failures in 15 hours with 2.6.18, rather than a whole lot of failures
with 2.6.16.  I guess I will have to try 2.6.19 or even something newer.

--
Len Sorensen