From owner-freebsd-stable@freebsd.org Tue Feb 5 21:11:58 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BA38E14D0AA7 for ; Tue, 5 Feb 2019 21:11:58 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2m.ore.mailhop.org (outbound2m.ore.mailhop.org [54.149.155.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0BA4E6AB63 for ; Tue, 5 Feb 2019 21:11:57 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1549400088; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=rsoWQzQQAbPyXU1/Fy/rOaordDNgmw3L9DUxCpzItHpsn5tNaKA7iZQVPO5JVFjnNvg/7CFiet3cE JWGgxuxRZ62a3OGFZhipQgl7Rmz02WKY3lXZgyis79iSXPxzx7KjSXUqHfYBhVa08k94qbJEhaYJD3 SRRp1DKdPDikSB/A3brScarG4i6iJwxcA5japmGwld5xejnAYgh7hDbakS4iqu16BAbbuaqq8ZTTAN NLT7gHKTVrIu3PTN9Bn0kRuwXXf8KjBuVIIlHCZJQ9AA8UQKRLYVjx9LKi2DbYfO9uO/Z5D2q00MPs 7ET/77Gf4CV2OUi2RBdTZUAsksqgw7w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=Ivvt6TAqy7e1dZT9uDsbBoY7V+2eLFsgTmBQHPvkPHg=; b=OKp78ouWGgPVnReTLcgi8pK3hjFq6UnqGuDdtj2XpHWB554wfWKDkNIgiyOOEvo2tr2w09uVXgl1S eBYZq6G86mX3ByAbumno0z1hxbY3nF46BxhiopoHcGxj1M/u6Lr9pPWAvewsUxVJLlEQJ2WGW4oxkF 4I6L4XdP9qshAVTw6uzDuXBD+PEG9/p7NqY4erlE/C/aaW1lPN01irkcpBHGp28gUqXNc1pOHalHc4 R/BS26w3j21zhjVrHLZ4AQ+ms09ot3Nn+REl0lx7nDlupGKy9oZtoVZh6NoPVUABk8KjrhOsALpZ4y oIFewOI1AYlecpITb1BbUjREcz09MaQ== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=Ivvt6TAqy7e1dZT9uDsbBoY7V+2eLFsgTmBQHPvkPHg=; b=IzLPXb9msRvcc+iOUvL3aHNq1x4HUEc26KeqO04+Cox06yxxybqVxJ5M0wFIhDNG3oGmo6NXenAVz jUSiLQ4TbDPvcXZYS0O2/RLtq3tTYrQPOdEDeBMnD/tLktG7xndYexA3+dgNpmAbu517TZkYYZTSQU LvobBDFzZ4XPU2eg3ikh1X4I1LtASt77+5n2Q92x631lHPgOaDH4xgxziQ3VhjNBQ3r8n8APyW47ov HbjatwHRLFAV2y+SD58pJISFkV/2pMxu/04QMDtT/boyqKLa7w5xgx2nhUs5AzwUWMsYAdZ3fdcxBZ +WyV+t8DWyJACN+Pt9U8W/iaVDEFSSA== X-MHO-RoutePath: aGlwcGll X-MHO-User: 44f5ee0a-2988-11e9-befd-af03bedce89f X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 44f5ee0a-2988-11e9-befd-af03bedce89f; Tue, 05 Feb 2019 20:54:47 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x15Ktk2T038485; Tue, 5 Feb 2019 13:55:46 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <3954a6fd232be453e8632159892250cb3ae47d08.camel@freebsd.org> Subject: Re: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-19:05.kqueue From: Ian Lepore To: Eugene Grosbein Cc: FreeBSD Date: Tue, 05 Feb 2019 13:55:46 -0700 In-Reply-To: References: <20190109194030.DFE3A8CC7@freefall.freebsd.org> <20190205195416.5ddsmc4rf7og4ece@mutt-hbsd> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 0BA4E6AB63 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.97 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.97)[-0.972,0]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 21:11:59 -0000 On Wed, 2019-02-06 at 03:46 +0700, Eugene Grosbein wrote: > 06.02.2019 3:18, Ian Lepore wrote: > > > > 2019, of course. re@ does NOT make mistakes. What you fail to > > > realize is that NIST was using kqueue to check their atomic > > > clock, and > > > they lost the race. Enjoy the rest of 2020. > > > -Alan > > > > > > > I think you meant that as a joke, but the reality is that NIST > > measures > > their atomic clocks using gear that runs FreeBSD (made by the > > company I > > work for). :) > > I do not know if it is related or not: some months ago my FreeBSD > 11.2-STABLE box > having GPS received attached at /dev/cuau0 for my local ntpd stratum > 1 server > went to late of 2020 insanely. I was forced to comment GPS out of > ntpd config to revive it > but I lost all data in hundreds of local RRD databases and > I found a race in libarchive being a reason why my backups had not > most part of databases. > > I still do not know exact reason and use Internet time source instead > of local GPS. The GPS week number rolls over in April 2019. At $work we have already been seeing glitches in gps receivers as early as last June that were caused by errors in the receivers' firmware that didn't handle the upcoming rollover properly. When a receiver first powers on, it has no real idea what gps era it's in (right now we're in the 2nd, about to roll over to the 3rd). It has to guess, which it mostly does the same way as software does that has to deal with 2-digit years: make a decision based on the current date being before/after some cutoff (like > 70 means 2070), and assume everyone will be running newer firmware before that date arrives. So your problem was most likely the gps receiver making a bad choice before it had enough info to make a good choice. It's one of many reasons why an ntp server should have at least 3 (really, at least 5) peers, so it can reject obviously-insane data from a single source. Even when you use a gps to get really accurate local time, you should have a handful of network peers that can serve as sanity-checkers. -- Ian