Danny Mayer wrote: > One thing that we could do for you is to make the move_fd() code do > nothing by creating an #ifdef NO_MOVE_FD option so that AIX can specify > to ignore it.
This seems like a good idea since it's so broken right now. You probably want to default IPv6 support off for AIX5 as well. > It is mature but the ideosyncrasies of the AIX implementation of the IP > stacks is causing unnecessary problems. > I think that basically these are the same thing. The real problem here > is that the IPv6 wildcard socket is trying to grab the IPv4 wildcard too > and it's already bound which is what is causing it to fail. This is a > bug in the O/S since it shouldn't be doing that. If we can identify specific problems, we will try to open PMRs with IBM to correct/track the issues. >> 598: This is interesting since it also complains about the xntpd IBM >> ships (which we currently use as well). We have had some issues with >> the clocks jumping back to 0:00...1970 after reboots; I believe we >> finally convinced IBM there was a problem. The other issues discussed >> in this bug I am not sure about; we'll have to investigate and see if >> they are contributing to time related pecularities. > This is probably an O/S issue where NTP is not able to retrieve or set > the clock properly. FYI, the reset-to-1970 issue we encountered (and got IBM to fix) would infrequently occurr after a sudden power loss; it would not update later as is suggested by #598. The only other "ntp is unreliable" issue we have had with the old xntpd was tracked down to a priority issue (xntpd was getting starved for CPU, messing up the algorithms). Now that I have a v4 ntpd hacked into functioning on AIX5, we plan to deploy it in some of our test runs to see how things behave. _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
