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]

Date:	Mon, 09 Mar 2009 21:42:37 +0100
From:	Jesper Krogh <jesper@...gh.cc>
To:	john stultz <johnstul@...ibm.com>
CC:	Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Len Brown <len.brown@...el.com>
Subject: Re: Linux 2.6.29-rc6

john stultz wrote:
> On Wed, 2009-03-04 at 18:39 -0800, john stultz wrote:
>> On Wed, 2009-03-04 at 10:57 -0800, John Stultz wrote:
>>> On Wed, 2009-03-04 at 19:36 +0100, Jesper Krogh wrote:
>>>> jk@...d12:~$ python drift-test.py 10.192.96.19
>>>> 04 Mar 19:27:10         offset: -0.157696       drift: -693.0 ppm
>>>> 04 Mar 19:28:10         offset: -0.195134       drift: -625.098360656 ppm
>>>> 04 Mar 19:29:10         offset: -0.232579       drift: -624.595041322 ppm
>>>> 04 Mar 19:30:10         offset: -0.270021       drift: -624.408839779 ppm
>>>> 04 Mar 19:31:11         offset: -0.307461       drift: -621.727272727 ppm
>>>> 04 Mar 19:32:11         offset: -0.344903       drift: -622.185430464 ppm
>>>> 04 Mar 19:33:11         offset: -0.382345       drift: -622.491712707 ppm
>>>> 04 Mar 19:34:11         offset: -0.419794       drift: -622.727488152 ppm
>>>> 04 Mar 19:35:11         offset: -0.457239       drift: -622.89626556 ppm
>>>
>>> Yea, so from this and the settled ntpdc -c kerninfo data before, we can
>>> see that the drift is further out then the 500ppm NTP can handle.
>>>
>>> So with that at least confirmed, we can focus back on to the fast-pit
>>> tsc calibration code.
>>>
>>> Ingo, Thomas: I'm missing a bit of the context to that patch, other then
>>> just speeding up boot times, was there other rational for moving away
>>> from the ACPI PM timer based calibration?
>>>
>>> Could we maybe add a quick test that the pit reads actually take the
>>> assumed 2us max? Doing this maybe via the HPET/ACPI PM?
>> Hey Jesper,
>>
>> 	Here's a very-hackish patch to see if the approach I'm considering
>> might fix the issue you're hitting. Could you apply it, boot the kernel
>> a few times and send me the following segments of the dmesg for each of
>> those boots (the example below is from my test box)? 
>>
>> tsc delta: 44418024
>> ref_freq: 3000100  pit_freq: 3000384
>> TSC: Fast PIT calibration matches PMTIMER.
>> TSC: PIT calibration matches PMTIMER. 1 loops
>> Detected 3000.045 MHz processor.

Hi John.

Patched into 2.6.28.7 ..

First boot.
[    0.000000] tsc delta: 34203220
[    0.000000] ref_freq: 2311825  pit_freq: 2310386
[    0.000000] TSC: Fast PIT calibration matches PMTIMER.
[    0.000000] TSC: PIT calibration matches PMTIMER. 2 loops
[    0.000000] Detected 2311.877 MHz processor.
Second boot:
[    0.000000] tsc delta: 34200313
[    0.000000] ref_freq: 2311803  pit_freq: 2310190
[    0.000000] TSC: Fast PIT calibration matches PMTIMER.
[    0.000000] TSC: PIT calibration matches PMTIMER. 2 loops
[    0.000000] Detected 2311.876 MHz processor.
Third boot:
[    0.000000] tsc delta: 34198686
[    0.000000] ref_freq: 2311824  pit_freq: 2310080
[    0.000000] TSC: Fast PIT calibration matches PMTIMER.
[    0.000000] TSC: PIT calibration matches PMTIMER. 1 loops
[    0.000000] Detected 2311.872 MHz processor.
Fourth boot:
[    0.000000] tsc delta: 34199433
[    0.000000] ref_freq: 2311831  pit_freq: 2310130
[    0.000000] TSC: Fast PIT calibration matches PMTIMER.
[    0.000000] TSC: PIT calibration matches PMTIMER. 2 loops
[    0.000000] Detected 2311.821 MHz processor.



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