TTY input censored too slow to return data

[adfelippe]

Hi everyone,

I've recently noticed a very odd behavior on my system (running on an AT91SAM9G15): Despite the fact I'm reading serial port continuously, TTY driver takes sometimes 1,2s to deliver data from the input censored.
Thing is: I'm not losing any data, it just takes too many calls to read for it to come.

Maybe my code will help to explain the problem.

First off, I set my serial port:

Code: Select all

/* 8N1 */
tty.c_cflag = (tty.c_cflag & ~CSIZE) | CS8;
/** Parity bit (none) */
tty.c_cflag &= ~(PARENB | PARODD);
/** Stop bit (1)*/
tty.c_cflag &= ~CSTOPB;
/* Noncanonical mode */
tty.c_lflag = 0;
tty.c_oflag = 0;
tty.c_cc[VMIN] =  0;
tty.c_cc[VTIME] = 0;

Later on, select is called:

Code: Select all

s_ret = select(rfid_fd + 1, &set, NULL, NULL, &port_timeval);

So read() can make its magic:

Code: Select all

switch (s_ret)
{
	case SRET_TIMOUT:
		//Timeout do rfid sem ler nada
		//CRTCL_PRINTF(D_RFID_MSG, "Select Timeout\n");
		sem_post(&sem_rfid);
		return u16_recv_len;
	case SRET_ERROR:
		//CRTCL_PRINTF(D_RFID_MSG, "Error: Select Timeout\n");
		sem_post(&sem_rfid);
		register_error(EM_RFID,EM_RFID_SELECT_FAILURE);
		return -EINTR;
	default:
		if ((rd_ret = read(rfid_fd, &recv_buff[u16_recv_len], (u16_req_len - u16_recv_len))) > 0)
		{
			u16_recv_len += rd_ret;
		}
		break;
}

Right afterwards, if I keep reading serial port for 15s for example, for several times I can see no data coming and that data, which I know arrived on time (it's timestamped), comes late. Delays in fetching data from input censored may vary from 300ms to 1,5s.

I've tried every kind of setting I could think of. It's tricky now since I don't know if at91 UART drivers aren't delivering data to tty driver or tty driver isn't fetching it? which is which here?

Any help would be appreciated.

[blue_z]

It's tricky now since I don't know if at91 UART drivers aren't delivering data to tty driver or tty driver isn't fetching it? which is which here?

The issue is not likely to be in the kernel (even though you neglect to mention the version).
I.E. how come you're the first to encounter this alleged "kernel bug"?
So it's probably in your code (of which you only provide snippets).

Your termios initialization as shown is incomplete (and not POSIX compliant).

Regards