I've traced what appears to be a bug in the serial driver (serial.c) in
regards to how the transmit fifo is handled on some uarts.
In the function transmit_chars() around line 6016:
count = info->xmit_fifo_size;
do {
serial_out(info, UART_TX, info->xmit.buf[info->xmit.tail]);
info->xmit.tail = (info->xmit.tail + 1) & (SERIAL_XMIT_SIZE-1);
info->state->icount.tx++;
if (info->xmit.head == info->xmit.tail)
break;
} while (--count > 0);
This loop fills the xmit fifo with up to the number of characters which the
fifo can hold. If we have more characters to send than the fifo can handle,
we will take an interrupt when the fifo empties and run this loop again.
The assumption is however that the fifo empty interrupt will occur when the
number of characters in the xmit fifo is 0. This is true on a 16550A uart,
but is not true on others (such as a ST16C654.) The ST16C654 uart has a 64
byte fifo, but the interrrupt will occur when the number of characters drops
below a programmable threshold. The minimum threshold is 8 on this uart
which causes an overflow of the xmit fifo.
My thought for a patch is to add a field to struct async_struct to indicate
the maximum number of characters which still may be in the fifo when an
interrupt occurs. The only other thing I can think of is to poll the fifo
full bit which every character write, but this seems like a bad idea.
I'd like to get some feedback before I code up a patch. Maybe I'm just
missing the bigger picture :-)
Thanks,
-- Bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Feb 23 2003 - 22:00:19 EST