linux-kernel - Re: Linux 2.6.29-rc6

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.00.0903151146550.3131@localhost.localdomain>
Date:	Sun, 15 Mar 2009 12:02:21 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jesper Krogh <jesper@...gh.cc>
cc:	john stultz <johnstul@...ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Len Brown <len.brown@...el.com>
Subject: Re: Linux 2.6.29-rc6

On Sun, 15 Mar 2009, Jesper Krogh wrote:
> > > 
> > > [    0.000000] Fast TSC delta=34227730, error=6223+6219=12442
> > > [    0.000000] Fast TSC calibration using PIT
> > > [    0.000000] Detected 2312.045 MHz processor.
> 
> My conclusion was that I would get a time reset after some time since the
> offset just increased as time went by (being reasonably small at the
> beginning).
> 
> I had it up for around 30 minutes... Should I have tested longer?

It would be good to test longer. Your previous emails showed:

	2.6.26: time.c: Detected 2311.847 MHz processor.
	2.6.29: Detected 2310.029 MHz processor.

where that first one was a successful boot, and the second one was a 
failing one. So let's assume that 2311.847 is the "correct" frequency.

The difference between the correct one and your failing one is ~790 ppm, 
which is above the 500ppm ntpd threshhold. And as we saw earlier, those 
differences were pretty consistent, ie in your list of four successive 
boots, the old code consistently gave a frequency error that was roughly 
.7 permille off (ie exactly that 700 ppm).

HOWEVER! With that patch you just tried, you got 

	Detected 2312.045 MHz processor.

and the difference between _that_ and the assumed-correct-one is actually 
just 85 ppm. Which should be perfectly fine.

[ With the "test against PM timer, you had:

	[    0.000000] ref_freq: 2311825  pit_freq: 2310386
	[    0.000000] ref_freq: 2311803  pit_freq: 2310190
	[    0.000000] ref_freq: 2311824  pit_freq: 2310080
	[    0.000000] ref_freq: 2311831  pit_freq: 2310130

  on four boots, so averaging them gives 2311.82 Mhz, and the 2312.045MHz 
  you got with the improved fast-PIT code is still _way_ below 500ppm from 
  that - it's ~95 ppm away.

  IOW, the new frequency realy looks likely to work. ]

Quite frankly, we don't know how exact the PM-timer is either - we just 
know that the detection is "stable" (but so was the old PIT timer 
detection: it was stably at 700ppm lower from the PM timer. So there is 
nothing that says that 2311.82Mhz is the "correct" frequency, but we 
obviously know from your ntpd saga that it is much closer to correct than 
the old 2310.029 was.

End result of all this: I'd really like you to try the modified PIT 
frequency code for longer. Also, remember that getting one (or a couple) 
"time reset" messages from ntpd while it's trying to sync up is not a 
problem per se - it can validly take a while to synchronize. The problem 
is literally only if it doesn't synchonize over time at all.

			Linus
--
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/