Re: Serial driver hangs

From: Roland CaÃebohm
Date: Wed Sep 29 2004 - 09:10:59 EST


Am Mittwoch, 29. September 2004 15:17 schrieb Paul Fulghum:
> Roland CaÃebohm wrote:
> > I have made a little test, at which the receive interrupt
> > is disabled in that state. It seems to be no improvement
> > to the solution of just trow away the bytes of the FIFO.
> > In both cases characters got lost.
>
> How did you reenable the receive interrupt in your test?

I have added a routine to "struct tty_driver" for restarting
the RX interrupt after TTY_DONT_FLIP bit is cleared in
read_chan().

>>>>>>>>>>>>
clear_bit(TTY_DONT_FLIP, &tty->flags);
if (tty->driver.restart_rx)
tty->driver.restart_rx(tty);
>>>>>>>>>>>>

and in the interrupt routine I have disabled the RX interrupt,
if TTY_DONT_FLIP is set.

>>>>>>>>>>>>
if (tty->flip.count >= TTY_FLIPBUF_SIZE)
{
info->IER &= ~UART_IER_RDI;
serial_outp(info, UART_IER, info->IER);
return; // if TTY_DONT_FLIP is set
}
>>>>>>>>>>>>

and tty->driver.restart_rx() is:

>>>>>>>>>>>>
static void rs_restart_rx(struct tty_struct *tty)
{
struct async_struct *info = (struct async_struct
*)tty->driver_data;
unsigned long flags;

if (serial_paranoia_check(info, tty->device,
"rs_restart_rx"))
return;

save_flags(flags); cli();
if (!(info->IER & UART_IER_RDI)) {
info->IER |= UART_IER_RDI;
serial_out(info, UART_IER, info->IER);
}
restore_flags(flags);
}
>>>>>>>>>>>>

It seems to take to long time in read_chan(). Do you now what
is the exact reason of locking the filp buffer with the
TTY_DONT_FLIP flag? For a short look I would say the buffers
are safe locked by the spinlock tty->read_lock.

Roland
--
___________________________________________________

VS Vision Systems GmbH, Industrial Image Processing
Dipl.-Ing. Roland CaÃebohm
Aspelohe 27A, D-22848 Norderstedt, Germany
Mail: roland.cassebohm@xxxxxxxxxxxxxxxx
http://www.visionsystems.de
___________________________________________________
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/