[argyllcms] Re: ubuntu-10.10-desktop-amd64: dispcal -D5 -? hangs

  • From: "Hal V. Engel" <hvengel@xxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Sat, 23 Apr 2011 16:32:41 -0700

On Saturday, April 23, 2011 05:19:05 AM Gerhard Fuernkranz wrote:
> Am 21.04.2011 06:06, schrieb Graeme Gill:
> > Gerhard Fuernkranz wrote:
> >>> If open() blocks on a serial port, then a typical reason is that modem
> >>> control is enabled for this tty (i.e. the CLOCAL flag not set, see
> >>> "man termios"), but the attached device does not assert the DSR
> >>> signal. I.e. open() waits until the device reports "I am ready".
> >> 
> >> Invoke "stty -a -F /dev/ttyS2" in order to check the settings of the
> >> tty. Look for "clocal" (-> no modem control) versus "-clocal" (-> modem
> >> control) in the output.
> > 
> > Hi Gerhard,
> > 
> >     is there anything I could do from a progromatic point of
> > 
> > view to avoid such a hang ?
> 
> Hello Graeme,
> 
> you can use pass the O_NONBLOCK flag to open() in order to avoid that it
> blocks. Using O_NONBLOCK is also a prerequisite for turning turn on the
> CLOCAL flag, because tcsetattr() requires an open file descriptor. Take
> care however, that subsequent read() and write() calls will be
> non-blocking too, when the tty was opened with O_NONBLOCK (e.g. read()
> would then immediately return -1, with errno==EAGAIN, if no buffered
> received data are available for immediate retrieval, and not wait for
> data).
> 
> > Presumably I don't want to alter the CLOCAL flag for a serial port that
> > isn't connected to an instrument. Perhaps there's a better way of
> > getting a list of potential instrument serial ports that doesn't
> > involve opening them ?
> 
> Unfortunately I don't know any method either for enumerating existing
> serial ports in Linux. But even if such a function was available, one
> would still not know which kind of device is connected to the port w/o
> trying to talk to the device. In order not to conflict with other programs
> which are currently accessing serial ports (e.g. getty, minicom, etc.),
> you could try to lock a serial port before accessing it (keeping it locked
> as long you keep it open, and don't touch ports which can't be locked).
> IMO most program accessing serial ports use UCCP-style lock files
> (residing in the directory /var/lock/ on Linux, e.g.
> /var/lock/LCK..tty<XX>). See
> http://docs.freebsd.org/info/uucp/uucp.info.UUCP_Lock_Files.html. For
> instance, when I connect minicom to tty8, then I see the following file
> 
> # cat /var/lock/LCK..tty8
>       15605 minicom root
> 
> which prevents other applications honoring UUCP lock files from accessing
> the port simultaneously.
> 
> Regards,
> Gerhard

This may work for some situations but it is far from fool proof.  One example.  
I have a time keeping serial GPS connected to my system (Motorola Oncore UT+) 
that is used by ntp for precise time keeping (< +- 1 microsecond after it has 
stabilized).  Nothing related to this including the kernel module that creates 
the interrupt from the one second pulse that marks the epoch or ntp creates a 
lock of any kind.  Messing with this serial port could cause a time keeping 
failure on systems like mine.   This type of set up is not common since Pulse 
Per Second (PPS) support was only added to the linux kernel recently (2.6.32 - 
FreeBSD has had this for several years now and is the reference 
implementation) but I suspect that PPS support is only one example of systems 
that do not create locks when using a serial port.  

Does the PPS system on FreeBSD create a lock on the PPS port?  Perhaps these 
systems should?

In the above case the system views the port as two devices.  The PPS signal 
from the reference clock (GPS in this case) is connected to the DCD pin of the 
serial port and the kernel module createds a PPS device to expose this to the 
system if PPS line disipline is setup for the port.  The rest of the serial 
port is just a normal serial device and it is used to read the serial data 
stream from the GPS so that ntp knows which second is marked by the pulse.  
Standardized sym links are used to expose these devices to ntp.

Hal

Other related posts: