linux-kernel - Re: [patch?] s2ram + P4 + tsc = annoyance

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-next>] [day] [month] [year] [list]

Date:	Thu, 27 Dec 2007 12:09:28 -0600
From:	Robert Hancock <hancockr@...w.ca>
To:	Mike Galbraith <efault@....de>
Cc:	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>
Subject: Re: [patch?] s2ram + P4 + tsc = annoyance

Mike Galbraith wrote:
> Greetings,
> 
> s2ram recently became useful here, except for the kernel's annoying
> habit of disabling my P4's perfectly good TSC.
> 
> [  107.894470] CPU 1 is now offline
> [  107.894474] SMP alternatives: switching to UP code
> [  107.895832] CPU0 attaching sched-domain:
> [  107.895836]  domain 0: span 1
> [  107.895838]   groups: 1
> [  107.896097] CPU1 is down
> [    3.726156] Intel machine check architecture supported.
> [    3.726165] Intel machine check reporting enabled on CPU#0.
> [    3.726167] CPU0: Intel P4/Xeon Extended MCE MSRs (12) available
> [    3.726170] CPU0: Thermal monitoring enabled
> [    3.726175] Back to C!
> [    3.726708] Force enabled HPET at resume
> [    3.726775] Enabling non-boot CPUs ...
> [    3.727049] CPU0 attaching NULL sched-domain.
> [    3.727165] SMP alternatives: switching to SMP code
> [    3.727858] Booting processor 1/1 eip 3000
> [    3.727862] CPU 1 irqstacks, hard=b042f000 soft=b042d000
> [    3.738173] Initializing CPU#1
> [    3.798912] Calibrating delay using timer specific routine.. 5986.12 BogoMIPS (lpj=2993061)
> [    3.798920] CPU: After generic identify, caps: bfebfbff 00000000 00000000 00000000 00004400 00000000 00000000 00000000
> [    3.798931] CPU: Trace cache: 12K uops, L1 D cache: 8K
> [    3.798934] CPU: L2 cache: 512K
> [    3.798936] CPU: Physical Processor ID: 0
> [    3.798938] CPU: After all inits, caps: bfebfbff 00000000 00000000 0000b080 00004400 00000000 00000000 00000000
> [    3.798946] Intel machine check architecture supported.
> [    3.798952] Intel machine check reporting enabled on CPU#1.
> [    3.798955] CPU1: Intel P4/Xeon Extended MCE MSRs (12) available
> [    3.798959] CPU1: Thermal monitoring enabled
> [    3.799161] CPU1: Intel(R) Pentium(R) 4 CPU 3.00GHz stepping 09
> [    3.799187] checking TSC synchronization [CPU#0 -> CPU#1]:
> [    3.819181] Measured 63588552840 cycles TSC warp between CPUs, turning off TSC clock.
> [    3.819184] Marking TSC unstable due to: check_tsc_sync_source failed.
> 
> I wonder why I'm the only guy in the galaxy experiencing this.  Does
> everybody else's clock continue to move forward across resume or
> something?  Anyway, I asked it to please stop doing that, and it
> complied without even exploding (unlike crabby APICs).

Are we missing some logic to resync the TSCs after resume, or something?

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@...pamshaw.ca
Home Page: http://www.roberthancock.com/

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