19

I've run into a problem where the open function never returns when I try to open a serial port. It doesn't happen all the time, and the problem disappears for a while if I unplug my USB to serial adapter and plug it back in. My code looks like this:

fileDescriptor = open(bsdPath, O_RDWR | O_NOCTTY);

where bsdPath is /dev/cu.KeySerial1 . I've tried adding the O_NONBLOCK option to the open command, but it still hangs.

Of course I'd like to understand why this is happening. My belief is that whatever the problem, with O_NONBLOCK specified, open should return no matter what even if it was unable to open the port. If it's unable to open the port, fileDescriptor should be -1 and errno should be set (I check for this immediately after the call to open). Of course, this isn't happening. Is my assumption incorrect? Is there some known reason for open() to never return even with O_NONBLOCK specified when an error is encountered?

Using the latest version of the Prolific PL-2303 driver with a PL-2303 based USB to serial adapter on 10.7.2, I've been able to reproduce this problem again today. A few notes:

  • When hung in the open() call, the process is not interruptible using command-. (control-C).
  • Running ps -avx shows a process state code of U for the process. I'm not sure what this code means. It doesn't appear in man pages for ps found by Googling. There is no listing of process state codes in the man page for ps on my machine. Perhaps it's specific to the Mac (10.4+?) version of ps?
  • I noted that on the run immediately before the first appearance of this problem, my call to ioctl() to reset the options on the port back to their state before I changed them for use in my program hung. I had to kill the program (via Xcode's debugger). Immediately after this, on the next launch of the program, open() hung...
jww
  • 97,681
  • 90
  • 411
  • 885
Andrew Madsen
  • 21,309
  • 5
  • 56
  • 97

1 Answers1

5

The problem is likely in the device driver. You are correct about how O_NONBLOCK should behave, but it is up to the driver to implement that correctly. It would be helpful to know which version OS X and which USB to Serial device is being used.

Standard procedures would be to make sure the device is plugged directly into the CPU USB ports (not a hub), check cables, and check for updated drivers.

Also, when open() is blocking, is the process interruptible by control-c? If you look at the process with "ps -aux" while its blocked, what does the "STAT" field say?

Seth Noble
  • 3,233
  • 19
  • 31
  • Thanks for the answer. I've observed it with a Keyspan USA-19HS on 10.6 and 10.7, and have had a report from a user along with a stack trace showing the same problem using a PL-2303-based adapter on 10.7. I'll try to reproduce it again to find the answers to your two questions. – Andrew Madsen Jan 13 '12 at 00:54
  • I've updated the question with some new observations. Thanks again. – Andrew Madsen Jan 15 '12 at 22:13
  • 1
    'U' means the process is "uninteruptible", which typically means its waiting for a device driver to respond. OS X is a bit unusual in that drivers can run in application space, outside the kernel. The kernel passed your `open()` and `ioctl()` calls to the driver and then tells your process to wait for the result. It sounds like the driver has hung, leaving your process hung (but the kernel is safe). I found this thread about the PL-2303 doing exactly what you are seeing on 10.7 Lion. Maybe it will help: http://xbsd.nl/2011/07/pl2303-serial-usb-on-osx-lion.html – Seth Noble Jan 16 '12 at 02:38
  • Thanks! Just after I edited my question, I decided to try the osx-pl2303 driver. I pulled the source code from the original project page on SourceForge, and managed to build it (with some modifications) for Lion (64-bit). I even thought about releasing my updated source, but I hadn't seen the link you posted. Anyway, I haven't been able to reproduce the problem with a Keyspan adapter today, so I think it is a bug in the Prolific driver, and the solution is to use the driver you linked to, or one otherwise based on the osx-pl2303 code. (http://sourceforge.net/projects/osx-pl2303/) Thanks again! – Andrew Madsen Jan 16 '12 at 03:09