Asynchronous Communications with uftdi/ucom (Is there a bug?)

[Pierre-Luc Drouin]

Hi,

I am trying to communicate with a fan controller that uses a FTDI 
FT232BL chip with uftdi/ucom and I am having troubles with asynchronous 
communications on FreeBSD (7.2 amd64 and 8.0-RC1 amd64, although what I 
present here has been obtained with 8.0-RC1 amd64). The exact same code 
works perfectly on Linux (amd64 on the same machine). I got synchronous 
communications working, but it seems that in asynchronous 
communications, SIGIO is generated randomly and read statements produce 
either junk or return the EINT, "Interrupted system call" error.

What I did is to write simplified code where I only request the device 
to provide its status. I have a source file that performs this in 
synchronous mode (bigngtest.c) and another one that does this in 
asynchronous mode (bigngtestasync.c). I ran both codes while enabling 
debug mode for uftdi and ucom and I put the output to stdout and the 
output to dmesg in some files. I also created files where I put the 
output when running the same codes on Linux.

These files can be found in a bzipped2 tar file here: 
http://download.yousendit.com/Y1Ryc0wwdGpVbTlFQlE9PQ

To summarize, here is how I set asynchronous mode compared to 
synchronous mode, in a "diff" format
 >   struct sigaction saio;
<   fd=open(DEV, O_RDWR | O_NOCTTY);
 >   fd=open(DEV, O_RDWR | O_NOCTTY | O_NONBLOCK);
...
 >   /* Install the signal handler before making the device asynchronous */
 >   saio.sa_handler = signal_handler_IO;
 >   result = sigemptyset(&saio.sa_mask);
 >   if(result<0) {
 >       perror("sigemptyset");
 >       return 1;
 >   }
 >   saio.sa_flags = 0;
 >   sigaction(SIGIO,&saio,NULL);
 >
 >   /* Allow the process to receive SIGIO */
 >   fcntl(fd, F_SETOWN, getpid());
 >   /* Make the file descriptor asynchronous */
 >   fcntl(fd, F_SETFL, FASYNC);

Please let me know if there are additional commands that are required to 
set asynchronous mode correctly on FreeBSD. Otherwise, it looks like 
there might be a bug somewhere in a kernel driver...

Thank you!
Pierre-Luc Drouin