Serial Driver HW FIFO over flow and 64K tty buffer over flow
 

Hi All,

We are using the following architecture. root@ti-omap3-am3517-evm:~# cat /proc/cpuinfo Processor : ARMv7 Processor rev 7 (v7l) BogoMIPS : 597.64 Features : swp half thumb fastmult vfp edsp neon vfpv3 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x1 CPU part : 0xc08 CPU revision : 7

Hardware : OMAP3517/AM3517 EVM Revision : 0020 Serial : 0000000000000000

We are using Linux kernel version 2.6.32 root@ti-omap3-am3517-evm:~# uname -a Linux ti-omap3-am3517-evm 2.6.32.8 #71 PREEMPT Mon Nov 5 15:37:19 EST 2012 armv7l unknown

The issue (HW FIFO over flow) we are facing is with serial driver (driver/serial/8250.c) uart_rx_char(). The serial port has 64 bytes FIFO and it is configured to generate interrupt upon receiving 32 bytes.

We are reading/writing data from/to serial port at 460800 baud rate. The regression test runs over the period of 7-8 hours in which we send and receive data to/from the serial port. After a couple of hours what we see is that HWFIFO over flow happens and we have no clue why it is happening. We are assuming that either one of the following two things are happening.

1) The serial interrupt is skipped because other interrupts (Ethernet/ i2c and MMC (out of which we don't use MMC and i2c during the regression test ) in the systems takes too long that serial interrupts are skipped and by the time the serial ISR gets a chance to run the HW FIFO is already full.

2) The other assumption is that we must process the ISR in less than 1msec (one milisecond) as such 460800 bits per second => 460800/1000 ms ~= 460 bits/ms ~= 52bytes/ms and since we have configured serial port to generate interrupt at every 32 bytes it gives us 32/50 ms ~= 0.64 ms to complete ISR. ( I have ignred start and stop bit) but it gives rough estimated ball park.

How do I confirm the point 1 and point 2 I mentioned above? Any pointers will be appreciated.

We also assume that the 8250.c (serial driver) is fairly old and robust and it shouldn't behave the way it is for us.

Let me know if you need more information.

The 8250.c driver can be found at this weblink. http://lxr.free-electrons.com/source...v=2.6.32;a=arm

One more question I have is that the serial port used on our target board is ST16654 based which has following configuration.

[PORT_16654] = { .name = "ST16654", .fifo_size = 64, .tx_loadsz = 32, .fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_01 | UART_FCR_T_TRIG_10, .flags = UART_CAP_FIFO | UART_CAP_EFR | UART_CAP_SLEEP }

I checked the code and to me it looks rx trigger is set for 16 bytes wheres as tx trigger is set to 32 bytes (defined at http://lxr.free-electrons.com/source...6.32;a=arm#L62).

I recompiled the kernel with FTRACE support. Also, I made changes in 8250.c so that serial port rx and tx interrupt happens when the FIFO is 8 bytes full. (It was 16 bytes in rx direction and 32 bytes in tx direction). I observed that the HW FIFO overflow happened followed by 64k buffer over flow and I had a program that triggered the cat trace. Below is the out put of the trace. Does any one know why this HW over flow and 64k buffer over flow are happening? As far as 64K buffer over run is concerned I found that flush_to_ldisc keeps requesting buffers for a long time , but why I don't understand. Any pointers?

Attached are the information about trace and current kernel configuration.