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]

Message-ID: <49B6C2B8.7000407@krogh.cc>
Date:	Tue, 10 Mar 2009 20:42:48 +0100
From:	Jesper Krogh <jesper@...gh.cc>
To:	Thomas Gleixner <tglx@...utronix.de>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	john stultz <johnstul@...ibm.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Len Brown <len.brown@...el.com>
Subject: Re: Linux 2.6.29-rc6

Thomas Gleixner wrote:
> On Mon, 9 Mar 2009, Linus Torvalds wrote:
>> On Mon, 9 Mar 2009, Jesper Krogh wrote:
>>> First boot.
>>> [    0.000000] ref_freq: 2311825  pit_freq: 2310386
>>> Second boot:
>>> [    0.000000] ref_freq: 2311803  pit_freq: 2310190
>>> Third boot:
>>> [    0.000000] ref_freq: 2311824  pit_freq: 2310080
>>> Fourth boot:
>>> [    0.000000] ref_freq: 2311831  pit_freq: 2310130
>> It's really quite impressively stable, but the fast-PIT calibration 
>> frequency is reliably about 3/4 of a promille low. Or, put another way, 
>> the TSC difference over the pit calibration is just a _tad_ too small 
>> compared to the value we'd expect if that loop of pit_expect_msb() would 
>> really run at the expected delay of a 1.193182MHz clock divided by 256.
>>
>> And it's stable in that it really always seems to be off by a very similar 
>> amount. It's not moving around very much.
>>
>> I also wonder why it seems to happen mainly just to _you_. There's 
>> absolutely nothing odd in your system, neither a slow CPU or anything 
>> else that would stand out.
>>
>> Grr. Very annoyingly non-obvious.
> 
> Indeed. One hint is in the slow calibration path. 3 of 4 boots have:
> 
>>> [    0.000000] TSC: PIT calibration matches PMTIMER. 2 loops
> 
> So the slow calibration path detects some disturbance.
> 
> Jesper, can you please apply the following patch instead of Johns and
> provide the output for a couple of boots? The output is:
> 
> Fast TSC calibration using PIT
> tsc 43425305 tscmin 624008 tscmax 632610

First boot:
[    0.000000] Fast TSC calibration using PIT
[    0.000000] tsc 34202223 tscmin 474069 tscmax 500664
Second boot:
Here I didnt get above messages.. http://krogh.cc/~jesper/dmesg-boot2.txt
Third boot:
[    0.000000] Fast TSC calibration using PIT
[    0.000000] tsc 34199856 tscmin 470321 tscmax 502182
Forth boot:
[    0.000000] Fast TSC calibration using PIT
[    0.000000] tsc 34202008 tscmin 475510 tscmax 501501

The second one is really strange.. is'nt it?

While booting up I saw this one on the serial console..
root@...d12:~# hwclock --systohc
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access 
method.
root@...d12:~# hwclock --systohc --debug
hwclock from util-linux-ng 2.13.1
hwclock: Open of /dev/rtc failed, errno=2: No such file or directory.
No usable clock interface found.
Cannot access the Hardware Clock via any known method.

Jesper
-- 
Jesper

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