John, I see the same change in behaviour on my newish Pentium D 940. Here's what I posted this Monday to the "clocksource tsc unstable" thread, mistakenly thinking it belonged there: <quote> Now that you mention it - I am seeing something similar with kernel 2.6.22 on an Intel Pentium D 940 dual core processor (arbitrary selection of dmesg lines that appeared relevant): <5>[ 0.000000] Linux version 2.6.22-testing (ts@xenon) (gcc version 4.1.2 20061115 (prerelease) (SUSE Linux)) #1 SMP PREEMPT Mon Jul 9 10:57:22 CEST 2007 <6>[ 56.367608] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0 <6>[ 56.367867] hpet0: 3 64-bit timers, 14318180 Hz <4>[ 56.428897] Calibrating delay using timer specific routine.. 6399.40 BogoMIPS (lpj=3199704) <4>[ 56.438058] CPU0: Intel(R) Pentium(R) D CPU 3.20GHz stepping 04 <4>[ 56.509321] CPU1: Intel(R) Pentium(R) D CPU 3.20GHz stepping 04 <6>[ 56.510299] Total of 2 processors activated (12793.06 BogoMIPS). <4>[ 56.510527] ENABLING IO-APIC IRQs <6>[ 56.510792] ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 <6>[ 56.622869] checking TSC synchronization [CPU#0 -> CPU#1]: <4>[ 56.642971] Measured 16 cycles TSC warp between CPUs, turning off TSC clock. <4>[ 0.152000] Marking TSC unstable due to: check_tsc_sync_source failed. <6>[ 0.153000] Brought up 2 CPUs <4>[ 0.241000] migration_cost=2000 2.6.22-rc6-mm1 has it too, though without the backward jump in printk timestamps: <5>[ 0.000000] Linux version 2.6.22-rc6-mm1-testing (ts@xenon) (gcc version 4.1.2 20061115 (prerelease) (SUSE Linux)) #10 SMP PREEMPT Thu Jul 5 23:41:32 CEST 2007 <6>[ 0.160000] Total of 2 processors activated (12791.39 BogoMIPS). <4>[ 0.160000] ENABLING IO-APIC IRQs <6>[ 0.161000] ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 <6>[ 0.171000] checking TSC synchronization [CPU#0 -> CPU#1]: <4>[ 0.171005] Measured 96 cycles TSC warp between CPUs, turning off TSC clock. <4>[ 0.171005] Marking TSC unstable due to: check_tsc_sync_source failed. <6>[ 0.172000] Brought up 2 CPUs 2.6.21.6 is fine here, though: <5>[ 0.000000] Linux version 2.6.21.6-noinitrd (ts@xenon) (gcc version 4.1.2 20061115 (prerelease) (SUSE Linux)) #1 SMP PREEMPT Sat Jul 7 16:40:13 CEST 2007 <6>[ 59.776179] Total of 2 processors activated (12794.21 BogoMIPS). <4>[ 59.776403] ENABLING IO-APIC IRQs <6>[ 59.776657] ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 <6>[ 59.923347] checking TSC synchronization [CPU#0 -> CPU#1]: passed. <6>[ 59.943479] Brought up 2 CPUs <4>[ 60.198497] migration_cost=496 <6>[ 60.303586] Time: tsc clocksource has been installed. <6>[ 60.303678] Switched to high resolution mode on CPU 0 <6>[ 60.303974] Switched to high resolution mode on CPU 1 HTH </quote> Please let me know if you need the full dmesgs, or anything else. Thanks T. -- Tilman Schmidt E-Mail: [email protected] Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
Attachment:
signature.asc
Description: OpenPGP digital signature
- References:
- clocksource change of behavior in 2.6.22 compared to 2.6.20 causes massive system clock slowdown
- From: "Alessandro Suardi" <[email protected]>
- Re: clocksource change of behavior in 2.6.22 compared to 2.6.20 causes massive system clock slowdown
- From: Andrew Morton <[email protected]>
- Re: clocksource change of behavior in 2.6.22 compared to 2.6.20 causes massive system clock slowdown
- From: john stultz <[email protected]>
- Re: clocksource change of behavior in 2.6.22 compared to 2.6.20 causes massive system clock slowdown
- From: "Alessandro Suardi" <[email protected]>
- Re: clocksource change of behavior in 2.6.22 compared to 2.6.20 causes massive system clock slowdown
- From: john stultz <[email protected]>
- clocksource change of behavior in 2.6.22 compared to 2.6.20 causes massive system clock slowdown
- Prev by Date: Re: [PATCH 01/61] Rules on how to use sysfs in userspace programs
- Next by Date: Re: lguest, Re: -mm merge plans for 2.6.23
- Previous by thread: Re: clocksource change of behavior in 2.6.22 compared to 2.6.20 causes massive system clock slowdown
- Next by thread: Re: clocksource change of behavior in 2.6.22 compared to 2.6.20 causes massive system clock slowdown
- Index(es):