Am 01.11.10 04:10 schrieb(en) Greg KH:
On Sun, Oct 31, 2010 at 06:27:00PM +0100, Albrecht Dre? wrote:Am I simply too dumb to use the uart correctly, or is there some issue in the kernel causing this effect? I noticed that the function mpc52xx_uart_int_rx_chars() does not check the return value of tty_insert_flip_char(). If the system runs out of space (actually, the maximum buffer size used should be limited, in particular on embedded systems!), might this go undetected? This might explain the bigger "chunks", as the '5200's uart has a rather big fifo (512 bytes).That might help, have you tried changing this and seeing if it fixes anything?
Hmmm, apparently it's not possible to disable the fifo completely in this chip if I interpret the manual correctly. I played with the fifo alarm levels (the number of space left in the fifo to immediately trigger an irq), though, and it doesn't change anything.
Also, are you sure your userspace application is checking the return value of write() to verify that it really wrote everything it thought it did?
The UART is connected to a ftdi usb/rs232 converter, and I write data using USB functions into the ftdi, which in turn sends them into the 5200's uart at 3 MBaud (yes, the wires are *very* short, and the uart doesn't see any framing or parity errors... ;-). And I am pretty sure the uart's rx register sees the correct number of bytes, as the TIOCGICOUNT ioctl reports exactly the number of bytes I sent. The rx counter is updated in the isr mpc52xx_uart_int_rx_chars() which reads data from the fifo, btw.
However, in this function I added a printk when tty_insert_flip_char() returns 0, and actually this happens when more than 64kb are sent quickly! Reading through the code, the following seems to happen:
- tty_insert_flip_char() detects that the struct tty_buffer is full and calls tty_insert_flip_string_flags()
- tty_insert_flip_string_flags() calls tty_buffer_request_room()
- tty_buffer_request_room() calls tty_buffer_find()
- tty_buffer_find() calls tty_buffer_alloc() if no free buffer is found
- tty_buffer_alloc() contains at the very beginning
if (tty->buf.memory_used + size > 65536)
return NULL;
I didn't add more debug output here, but for me it looks as if the kernel simply rejects buffering more than 64kByte. Could this be the correct interpretation of the path outlined above? If this is the case, then IMHO there is a serious problem, as data can be lost completely undetected, at least in any uart driver which ignores the return value of tty_insert_flip_char()!
Thanks,
Albrecht.
Attachment:
pgphQITYNd5yt.pgp
Description: PGP signature
