> -----Message d'origine----- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part de > Arne Georg Gleditsch > > Florian Attenberger <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
