And let's all just hope that a week or two of testing is enough when jumping a major piece of software forward several years in its independent evolution. The import of 4.2.8p2 several months ago resulted in complete failure of timekeeping on all my arm systems. Just last week I tracked it down to a kernel bug (which I haven't committed the fix for yet). While the bug has been in the kernel for years, it tooks a small change in ntpd behavior to trigger it. Granted it's an odd corner-case problem that won't affect most users because they just use the stock ntp.conf file (and it only affects systems that have a large time step due to no battery-backed clock). But it took me weeks to find enough time to track down the cause of the problem. I wonder how many other such things could be lurking in 4.2.8, waiting to be triggered by other peoples' non-stock configurations? We've already had one report for 4.2.8p3 of someone's GPS refclock not working after the update. -- Ian On Sun, 2015-07-12 at 18:49 +0900, Tomoaki AOKI wrote:> Wow! Thanks for your time and quick response. > I'm looking forward to seeing it MFCed. :-) > > On Sun, 12 Jul 2015 08:56:26 +0000 > Xin LI <delphij at gmail.com> wrote: > > > I've spent some time on the MFC, the testing would still take some time > > (likely a day or two) and once that's finished I'll ask re@ for approval. > > On Sat, Jul 11, 2015 at 11:44 PM Tomoaki AOKI <junchoon at dec.sakura.ne.jp> > > wrote: > > > > > As I already mentioned in another post, head has 4.2.8 p3 in-tree. > > > > > > So the answer should be MFC before creation of releng/10.2 is planned > > > or not. > > > > > > > > > On Sun, 12 Jul 2015 15:04:43 +1000 > > > Peter Jeremy <peter at rulingia.com> wrote: > > > > > > > On 2015-Jul-11 23:22:56 -0400, Chris Nehren < > > > cnehren+freebsd-stable at pobox.com> wrote: > > > > >On Sat, Jul 11, 2015 at 09:58:11 +1000, John Marshall wrote: > > > > >> It's me again with my annual NTP whinge. > > > > > > > > > >The answer to the perennial "will release $foo ship with old / insecure > > > > >/ otherwise deficient $bar?" is still "install $bar from ports". > > > > > > > > That's a non-answer. It just changes the question to "why bother to > > > > include $bar in base when I need to install the port anyway". > > > > > > > > -- > > > > Peter Jeremy > > > > > > > > > -- > > > Tomoaki AOKI junchoon at dec.sakura.ne.jp > > > _______________________________________________ > > > freebsd-stable at freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org" > > > > > _______________________________________________ > > freebsd-stable at freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org" > > > >
On 2015-Jul-12 09:41:43 -0600, Ian Lepore <ian at freebsd.org> wrote:>And let's all just hope that a week or two of testing is enough when >jumping a major piece of software forward several years in its >independent evolution.Whilst I support John's desire for NTP to be updated, I also do not think this is the appropriate time to do so. That said, the final decision is up to re at .>The import of 4.2.8p2 several months ago resulted in complete failure of >timekeeping on all my arm systems. Just last week I tracked it down to >a kernel bug (which I haven't committed the fix for yet). While the bug >has been in the kernel for years, it tooks a small change in ntpd >behavior to trigger it. > >Granted it's an odd corner-case problem that won't affect most users >because they just use the stock ntp.conf file (and it only affects >systems that have a large time step due to no battery-backed clock). >But it took me weeks to find enough time to track down the cause of the >problem.I'm not using the stock ntp.conf on my RPis and didn't notice any NTP issues. Are you able to provide more details of either the ntp.conf options that trigger the bug or the kernel bug itself? A quick search failed to find anything. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 949 bytes Desc: not available URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20150713/4fce046c/attachment.bin>
Bez?glich Ian Lepore's Nachricht vom 12.07.2015 17:41 (localtime):> And let's all just hope that a week or two of testing is enough when > jumping a major piece of software forward several years in its > independent evolution.?> I wonder how many other such things could be lurking in 4.2.8, waiting > to be triggered by other peoples' non-stock configurations? We've? I'd like to report one, most likely an upstream problem: 'restrict' definitions in ntp.conf(5) no longer work with unqualified DNS names. A line like "restrict time1 nomodify nopeer noquery notrap" results in: ntpd[1913]: line 7 column 7 syntax error, unexpected T_Time1 ntpd[1913]: syntax error in /etc/ntp.conf line 7, column 7 I've always been using unqualified hostnames with 'restrict', and since defining 'server' with unqualified hostname still works, this seems to be a significant bug to me. People are forced to change 'restrict' definitions, but not to also change other unqualified definitions, which potentially leads to misconfigurations, since intentionally matching definitions can now differ easily. Has anybody already noticed this problem? And any idea if upstream is aware?> On Sun, 2015-07-12 at 18:49 +0900, Tomoaki AOKI wrote: >> Wow! Thanks for your time and quick response. >> I'm looking forward to seeing it MFCed. :-) >> >> On Sun, 12 Jul 2015 08:56:26 +0000 >> Xin LI <delphij at gmail.com> wrote: >> >>> I've spent some time on the MFC, the testing would still take some time >>> (likely a day or two) and once that's finished I'll ask re@ for approval.Thanks, -Harry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20150724/d121b903/attachment.bin>