Subject: Re: ntpd problems with GPS receiver under NetBSD-amd64
To: Alicia da Conceicao <alicia@engine.ca>
From: Frank Kardel <Frank.Kardel@Acrys.COM>
List: port-amd64
Date: 02/03/2005 09:03:26
Hi Alicia,

see my comments interspersed below:

> Greetings:
>
> I have a GPS receiver with a TTL PPS feed, which I managed to successfully
> [...]
setup look to too far off
>
> Unfortunately ntpd fails with the following errors:
>
> 	ioctl(TIOCSCTTY, 0) fails for clock I/O: Operation not permitted
This is a failing call to get a controlling tty. I controlling tty is
currently needed to get SIGIO from the tty. It will not work if
ntp already has a controlling tty (usually when running in debug mode). Try
the start ntp without debug mode.

What I never understood is:
  For SIGIO you need a CTTY.
  There can only be one CTTY.
  Thus you can get only SIGIO from one CTTY. This seems
  to be the case with many BSD derived systems (*BSD, Ultrix).
  Solaris and SunOS3,4 don NOT have that restriction. And
  I would know why you would have to be a CTTY to use SIGIO.
  IO possible shouldn't be mixed up with tty signal like SIGINT,
  SIGQUIT, SIGHUP or is there another explanation like POSIX standard ?

  Due to this restriction NTP cannot run in debug mode or with several
  refclocks as SIGIO is only possible from the single CTTY.

  Maybe some BSD tty guru can enlighten me here.

> 	internal error: refclockio structure not found
> 	configuration of 127.127.20.0 failed
> 	reclock_atom: /dev/pps0: Interrupted system call
> 	configuration of 127.127.22.0 failed
>
> I could understand if there where some ntpd related issues regarding the
> NetBSD implimentation of PPS, even though I did enable it in the kernel.
> But considering that I can see a continuous stream of NMEA strings being
> sent by the GPS clock through the serial bus when I use minicom, I am at
> a loss as to why ntpd is failing for the NMEA pseduo-port at 127.127.20.0.
>
> Looking at the NetBSD kernel source code, the original of that EPERM errno
> value outputed by ntpd appears to originate in "/usr/src/sys/kern/tty.c"
> when ntpd attempts to do a "ioctl(rio->fd,TIOCSCTTY,0)" in
> "libntp/iosignal.c"
> to become a controlling tty.
Try logging to syslog and don't use debug. It' just doesn't work in
conjunction
with tty based refclocks and current SIGIO/CTTY semantics.

>
> Any suggestions is greatly apprecated.
>
> Thanks in advance.
> Alicia.
>
>
Regards
  Frank (also kardel (at) ntp d-o-t org)