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 for Android: free password hash cracker in your pocket

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

Date:	Sun, 15 Mar 2009 11:09:37 -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:
> Linus Torvalds wrote:
> > 
> > Regardless of whether is succeeds or not, it will print out some debug
> > messages, which will be interesting to see.
> 
> 
> [    0.000000] Fast TSC delta=34227730, error=6223+6219=12442
> [    0.000000] Fast TSC calibration using PIT
> [    0.000000] Detected 2312.045 MHz processor.

Ok. This claims that the error really is smaller than 500ppm (it's about 
360 ppm). Which is about what we're aiming for (in real life, the actual 
error is about half that - we're just adding up the error terms for 
maximum theoretical error).

> Using "ntpq -c peers" .. the offset steadily grows as time goes.
> 
> Full dmesg: http://krogh.cc/~jesper/dmesg-linux-2.6.29-rc8-linus1.txt
> 
> jk@...d11:~$ ntpdc -c kerninfo
> pll offset:           0.085167 s
> pll frequency:        -18.722 ppm
> maximum error:        0.137231 s
> estimated error:      0.008823 s
> status:               0001  pll
> pll time constant:    6
> precision:            1e-06 s
> frequency tolerance:  500 ppm

Hmm. But now it all seems to _work_, no? Or do you still get time resets? 
Now your "pll frequency" and "estimated error" are real values, not just 
"0s" like in your previous failure cases.

Of course, maybe that happens only after the time reset actually kicks in.

But one thing my patch did - apart from the error estimation - was to 
synchronize the TSC read with the actual PIT MSB wrap event. Maybe that 
mattered.

The other possibility (if the time reset actually happens) is that your 
PIT is simply not running at the expected frequency. That would be really 
quite odd, since that nominal 1193181.8181 Hz frequency is very standard, 
and has been around foreve.

I do not know how to test that. We need a reference timer to sync to, and 
the PIT has traditionally been a _lot_ more reliable than the other timers 
in the system (the PM timer may be reliable on modern machines, but almost 
certainly not on anything a few years old).

			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/