Re: Loosing chars on serial console in 2.4

[Russell King]

On Thu, Feb 13, 2003 at 03:03:35PM +0100, Joakim Tjernlund wrote:
> If I paste text into my serial console, some chars aren't echoed back. I
> also loose some chars when doing reboot and init starts to print messages.
> 
> This is due to that almost no user of opost() bothers to check its return
> value. The patch below fixes the problem, but it is ugly and possibly buggy. 
> I don't know how to fix this properly.

I suspect the real solution would be to add an "echo" queue to the tty
layer.  However, that's probably not a trivial change.

Although the problems with low latency tty's are now fixed in the patch
below (opost can be called from IRQ context), there is one concern
remaining that someone (not me) needs to consider.  What are the
locking implications of schedling here.

Bear in mind that the tty layer relies on the BKL, which is dropped when
we explicitly reschedule.

I'd suggest that the existing "dropping echo characters" behaviour is
probably better than the possible instability that could result here,
especially for 2.4.

I'll leave the final decision up to someone else, since I'm not actively
involved with tty stuff in 2.4.  Does someone else want to comment?

> HW: custom 860 board at 115200 baud, using the standard
> arch/ppc/8xx_io/uart.c driver.
> 
> --- drivers/char/n_tty.c	1 Nov 2002 13:43:27 -0000	1.1.1.1
> +++ drivers/char/n_tty.c	13 Feb 2003 13:45:33 -0000
> @@ -186,8 +186,14 @@
>  static int opost(unsigned char c, struct tty_struct *tty)
>  {
>  	int	space, spaces;
> +#if 1
> +	unsigned long tmo = jiffies + HZ/10;
>  
> +	while(!(space = tty->driver.write_room(tty)) && !in_interrupt() && !time_after(jiffies, tmo))
> +		cond_resched();
> +#else
>  	space = tty->driver.write_room(tty);
> +#endif
>  	if (!space)
>  		return -1;
>  

-- 
Russell King ([e-mail])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html