tcdrain() problem?

[Boszormenyi Zoltan]

Hi!

I use the serial line for communication with a device.
The communication looks like this:

1. ask the device about its state (a 4 byte packet)
2. read reply from device

3. decide what to do:
   3a. if nothing to do, go to 1.
   3b. if there is something to do, send the answer to the device
       this is a 23 byte packet
   3c. if the device ack'd the previous action, counter-ack it.

This is the function I use for sending:

void send_message(int fd, ptg_t *ptg, int sleeptime) {
        int     len;

/*	tcflush(fd, TCIOFLUSH); */
	if (sleeptime)
	        usleep(sleeptime);
	len = ptg->message_out[1];  
	write(fd, ptg->message_out, len);
	tcdrain(fd);
#if DEBUG
        {
         	int i;
         	printf("%d sent: ", ptg->ptgnum);
         	for(i = 0; i < len; i++)
         	        printf("0x%02x ", ptg->message_out[i]);
         	printf("\n");
        }
#endif   
}

The line is full duplex, 19200 baud, 8N1.
The serial device if opened with O_RDWR|O_NOCTTY|O_NDELAY.
My problem is that if the tcflush() is not there,
sometimes between the "there's something to do" reply 
and the longish answer somehow a "what state are you in?"
message goes out. This simply couldn't happen from the
program data flow. I have put printf()s into every possible place
and it does not show anything unusual.
But an independent serial line sniffer (another PC) shows the
above problem, no matter what the sleeptime is. (15000usec - 60000usec)

So I suspect that tcdrain() does not do what the manpage says:

       tcdrain()  waits  until  all  output written to the object
       referred to by fd has been transmitted.

The above problem happened on two different PCs, the only common
thing was the uart type: 16550A.

Both PCs are running the 2.2.17-14 RH kernel and glibc-2.1.3-22 (RH 6.2),
the serial driver compile options and version are from dmesg:

Serial driver version 4.27 with MANY_PORTS MULTIPORT SHARE_IRQ enabled

If I put the tcflush() before the write, the problem disappears.

Now the question is: Should I really issue a tcflush(), or is it a bug
in tcdrain()? Can O_NDELAY cause tcdrain() not to wait?

Please cc the answer, I am not on the list.

Regards,
Zoltan Boszormenyi