[ntp:hackers] Any NetBSD and/or tty ioctl gurus?
kardel at ntp.org
Mon Jan 16 13:06:48 UTC 2006
Hal Murray wrote:
>I'm trying to setup 3 refclocks on a vanilla PC running NetBSD 3.0 and ntp-dev
>The first clock works but the other two get this:
>26 Dec 21:13:05 ntpd: ioctl(TIOCSCTTY, 0) fails for clock I/O: Operation
>26 Dec 21:13:05 ntpd: configuration of 127.127.20.2 failed
>26 Dec 21:13:06 ntpd: ioctl(TIOCSCTTY, 0) fails for clock I/O: Operation
>26 Dec 21:13:06 ntpd: configuration of 127.127.26.3 failed
>The only place I find any reference to TIOCSCTTY is in libntp/iosignal.c
>I'm not familiar with the tty ioctls. The comment a few lines up is
> * another question is: how can you do multiple SIGIO from
> * ttys (as they all should be CTTYs), wondering...
>Anybody recognize this quirk?
My comment (old - but still true for some implementations).
> Does NetBSD just not support more than one
Stock NetBSD doesn't - as some other systems (All that define
USE_FSETOWNCTTY during autoconfig -
see configure.in) may not either.
>Seems to be that way. I found a note from the NetBSD on AMD-64 list that
>says only one. (0 if in debug mode.) It also says:
> 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).
>Looks like everybody agrees that this path won't work.
>How does this work on FreeBSD? Is there any good documentation for the tty
>ioctls and/or is there a reasonable chance of fixing this on NetBSD?
Fixed with NetBSD 3.99.8 (aka. some form of a current -current version)
and above - christos at netbsd.org removed that restriction from the tty
>I've seen suggestions of using the parallel port. (I don't remember if that
>was for 1 PPS signal or several.) I'd like to avoid that mostly for
>Maybe I should pop up a level. Is this a strange configuration?
no - but not really common.
> Is it silly
>to use more than one refclock on a system? I was hoping to be able to
Works somewhat - if they are of the same type they'll certainly compete
for resources (IO/timestamps) - especially
when they are in sync 8-). So the comparison is limited once you get down
into interrupt latency ranges.
More information about the hackers