[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <F1D642E5A91BC94D9504EC83AE19E6B0128A63@ecqcmtlmail3.quebec.int.ec.gc.ca>
Date: Tue, 3 Jul 2007 11:36:42 -0400
From: "Fortier,Vincent [Montreal]" <Vincent.Fortier1@...GC.CA>
To: "Arne Georg Gleditsch" <argggh@...phinics.no>,
"Florian Attenberger" <valdyn@...il.com>
Cc: <linux-kernel@...r.kernel.org>
Subject: RE: 2.6.21.5 june 30th to july 1st date hang?
> -----Message d'origine-----
> De : linux-kernel-owner@...r.kernel.org
> [mailto:linux-kernel-owner@...r.kernel.org] De la part de
> Arne Georg Gleditsch
>
> Florian Attenberger <valdyn@...il.com> writes:
> > yep, controlled by ntpd.
> > You're right according to
> > ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.33
> > that event shouldn't have been there.
>
> I'm not all that versed in ntp-ish, but it appears that the
> leap second insertion should be propagated through the ntp protocol.
> Whether the leap second in question came from a ntp server
> giving out wrong data or from a misinterpretation or bug in
> ntpd is of course hard to say, but either way turning the
> clock back is unlikely to reconstruct the circumstances. An
> interesting exercise might be to code up a small program to
> call adjtimex with timex.status |= STA_INS, to see if this
> can trigger the problem. (The bogus leap second might be a
> red herring entirely, of course...)
You are probably right, I did tried to reproduce the problem without
success...
Although it is wierd that it happend only on 2.6.21 kernels... It did
not happend on any of my workstations/servers running either 2.6.18 or
2.6.20.
Could dynticks be involved?
- vin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists