[RFC PATCH] x86:Use cpu_khz for loops_per_jiffy calculation

[RFC PATCH] x86:Use cpu_khz for loops_per_jiffy calculation

[Alok Kataria]

On X86 platform we can use the value of cpu_khz computed during tsc calibration
to calculate the loops_per_jiffy value. Its very important to keep the error in
lpj values to minimum as any error in that may result in kernel panic in
check_timer. 
In virtualization environment on a highly overloaded host, the guest delay
calibration may sometimes result in errors beyond the ~50% that timer_irq_works
can handle, resulting in the guest panicking.

This change could also help large MP systems in reducing their booting time.

Patch also does some formating changes to lpj_setup code to now have a single
printk to print the calculated bogomips value.

On top of current git.

Signed-off-by: Alok N Kataria <akataria@vmware.com>

Index: linux-2.6/arch/x86/kernel/time_64.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/time_64.c	2008-05-23 16:56:24.000000000 -0700
+++ linux-2.6/arch/x86/kernel/time_64.c	2008-06-03 17:28:46.000000000 -0700
@@ -123,6 +123,8 @@
 		(boot_cpu_data.x86_vendor == X86_VENDOR_AMD))
 		cpu_khz = calculate_cpu_khz();
 
+	lpj_tsc = ((unsigned long)cpu_khz * 1000)/HZ;
+
 	if (unsynchronized_tsc())
 		mark_tsc_unstable("TSCs unsynchronized");
 
Index: linux-2.6/include/linux/delay.h
===================================================================
--- linux-2.6.orig/include/linux/delay.h	2008-05-23 16:56:24.000000000 -0700
+++ linux-2.6/include/linux/delay.h	2008-06-03 17:28:46.000000000 -0700
@@ -41,6 +41,7 @@
 #define ndelay(x) ndelay(x)
 #endif
 
+extern unsigned long lpj_tsc;
 void calibrate_delay(void);
 void msleep(unsigned int msecs);
 unsigned long msleep_interruptible(unsigned int msecs);
Index: linux-2.6/init/calibrate.c
===================================================================
--- linux-2.6.orig/init/calibrate.c	2008-05-23 16:56:24.000000000 -0700
+++ linux-2.6/init/calibrate.c	2008-06-03 17:28:46.000000000 -0700
@@ -9,6 +9,7 @@
 #include <linux/init.h>
 #include <linux/timex.h>
 
+unsigned long lpj_tsc;
 unsigned long preset_lpj;
 static int __init lpj_setup(char *str)
 {
@@ -118,16 +119,14 @@
 
 	if (preset_lpj) {
 		loops_per_jiffy = preset_lpj;
-		printk("Calibrating delay loop (skipped)... "
-			"%lu.%02lu BogoMIPS preset\n",
-			loops_per_jiffy/(500000/HZ),
-			(loops_per_jiffy/(5000/HZ)) % 100);
+		printk("Calibrating delay loop skipped, "
+			"using preset value.. ");
+	} else if (lpj_tsc) {
+		loops_per_jiffy = lpj_tsc;
+		printk("Calibrating delay loop skipped, "
+			"using value calculated from tsc.. ");
 	} else if ((loops_per_jiffy = calibrate_delay_direct()) != 0) {
 		printk("Calibrating delay using timer specific routine.. ");
-		printk("%lu.%02lu BogoMIPS (lpj=%lu)\n",
-			loops_per_jiffy/(500000/HZ),
-			(loops_per_jiffy/(5000/HZ)) % 100,
-			loops_per_jiffy);
 	} else {
 		loops_per_jiffy = (1<<12);
 
@@ -161,12 +160,7 @@
 			if (jiffies != ticks)	/* longer than 1 tick */
 				loops_per_jiffy &= ~loopbit;
 		}
-
-		/* Round the value and print it */
-		printk("%lu.%02lu BogoMIPS (lpj=%lu)\n",
-			loops_per_jiffy/(500000/HZ),
-			(loops_per_jiffy/(5000/HZ)) % 100,
-			loops_per_jiffy);
 	}
-
+	printk("%lu.%02lu BogoMIPS (lpj=%lu)\n", loops_per_jiffy/(500000/HZ),
+		(loops_per_jiffy/(5000/HZ)) % 100, loops_per_jiffy);
 }
Index: linux-2.6/arch/x86/kernel/tsc_32.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/tsc_32.c	2008-05-27 12:28:16.000000000 -0700
+++ linux-2.6/arch/x86/kernel/tsc_32.c	2008-06-03 17:28:46.000000000 -0700
@@ -401,6 +401,7 @@
 void __init tsc_init(void)
 {
 	int cpu;
+	u64 lpj;
 
 	if (!cpu_has_tsc || tsc_disabled) {
 		/* Disable the TSC in case of !cpu_has_tsc */
@@ -421,6 +422,10 @@
 		return;
 	}
 
+	lpj = ((u64)cpu_khz * 1000);
+	do_div(lpj, HZ);
+	lpj_tsc = lpj;
+
 	printk("Detected %lu.%03lu MHz processor.\n",
 				(unsigned long)cpu_khz / 1000,
 				(unsigned long)cpu_khz % 1000);

Re: [RFC PATCH] x86:Use cpu_khz for loops_per_jiffy calculation

[Arjan van de Ven]

On Tue, 03 Jun 2008 17:41:09 -0700
Alok Kataria <akataria@vmware.com> wrote:

> On X86 platform we can use the value of cpu_khz computed during tsc
> calibration to calculate the loops_per_jiffy value. Its very
> important to keep the error in lpj values to minimum as any error in
> that may result in kernel panic in check_timer. 
> In virtualization environment on a highly overloaded host, the guest
> delay calibration may sometimes result in errors beyond the ~50% that
> timer_irq_works can handle, resulting in the guest panicking.
\

can you guarantee that the rate tsc ticks at is the same as the current
CPU frequency? Answer: You can't....

sadly we do need to calibrate this...

In addition, clearly you can have different cpus in a system run at a
different rate (both in terms of cpu_khz and, independently, in terms
of tsc rate)


-- 
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: [RFC PATCH] x86:Use cpu_khz for loops_per_jiffy calculation

[Alok kataria]

On Tue, Jun 3, 2008 at 6:20 PM, Arjan van de Ven <arjan@infradead.org> wrote:
> On Tue, 03 Jun 2008 17:41:09 -0700
> Alok Kataria <akataria@vmware.com> wrote:
>
>> On X86 platform we can use the value of cpu_khz computed during tsc
>> calibration to calculate the loops_per_jiffy value. Its very
>> important to keep the error in lpj values to minimum as any error in
>> that may result in kernel panic in check_timer.
>> In virtualization environment on a highly overloaded host, the guest
>> delay calibration may sometimes result in errors beyond the ~50% that
>> timer_irq_works can handle, resulting in the guest panicking.
> \
>
> can you guarantee that the rate tsc ticks at is the same as the current
> CPU frequency? Answer: You can't....
>

I think at the boot time atleast we can assume that, no ?
If you are referring to the cpu frequency changing at run time (aka
dynamic frequency scaling),
in that case the time_cpufreq_notifier should take care of updating
the loops_per_jiffy
value for that corresponding cpu.

> sadly we do need to calibrate this...
>
> In addition, clearly you can have different cpus in a system run at a
> different rate (both in terms of cpu_khz and, independently, in terms
> of tsc rate)
>

Again yes at run time frequency's may change but they shouldn't at boottime.
AFAIK, i don't think there are X86 MP systems with asymmetric cpus
i.e. systems with different
base frequencies. If thats not true then there sure is a problem.

Thanks,
Alok

>
> --
> If you want to reach me at my work email, use arjan@linux.intel.com
> For development, discussion and tips for power savings,
> visit http://www.lesswatts.org
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: [RFC PATCH] x86:Use cpu_khz for loops_per_jiffy calculation

[Arjan van de Ven]

On Tue, 3 Jun 2008 21:01:54 -0700
"Alok kataria" <alokkataria1@gmail.com> wrote:

> On Tue, Jun 3, 2008 at 6:20 PM, Arjan van de Ven
> <arjan@infradead.org> wrote:
> > On Tue, 03 Jun 2008 17:41:09 -0700
> > Alok Kataria <akataria@vmware.com> wrote:
> >
> >> On X86 platform we can use the value of cpu_khz computed during tsc
> >> calibration to calculate the loops_per_jiffy value. Its very
> >> important to keep the error in lpj values to minimum as any error
> >> in that may result in kernel panic in check_timer.
> >> In virtualization environment on a highly overloaded host, the
> >> guest delay calibration may sometimes result in errors beyond the
> >> ~50% that timer_irq_works can handle, resulting in the guest
> >> panicking.
> > \
> >
> > can you guarantee that the rate tsc ticks at is the same as the
> > current CPU frequency? Answer: You can't....
> >
> 
> I think at the boot time atleast we can assume that, no ?

Nope, absolutely not.
1) The rate TSC ticks may or may not be the maximum frequency (usually
is, but no guarantee)
2) The BIOS might not boot your system at the maximum frequency (think
"laptop on battery")... that's really up to the BIOS.

> 
> > sadly we do need to calibrate this...
> >
> > In addition, clearly you can have different cpus in a system run at
> > a different rate (both in terms of cpu_khz and, independently, in
> > terms of tsc rate)
> >
> 
> Again yes at run time frequency's may change but they shouldn't at
> boottime. AFAIK, i don't think there are X86 MP systems with
> asymmetric cpus i.e. systems with different
> base frequencies. If thats not true then there sure is a problem.

there's nothing that guarantees this. (Well maybe Dell's website does
because they want to sell you 2 expensive cpus rather than 1 cheap 1
expensive one ;-)

> 
> Thanks,
> Alok
> 
> >
> > --
> > If you want to reach me at my work email, use arjan@linux.intel.com
> > For development, discussion and tips for power savings,
> > visit http://www.lesswatts.org
> > --
> > To unsubscribe from this list: send the line "unsubscribe
> > linux-kernel" in the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> >


-- 
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: [RFC PATCH] x86:Use cpu_khz for loops_per_jiffy calculation

[Alok Kataria]

On Wed, 2008-06-04 at 06:16 -0700, Arjan van de Ven wrote:
> On Tue, 3 Jun 2008 21:01:54 -0700
> "Alok kataria" <alokkataria1@gmail.com> wrote:
> 
> > On Tue, Jun 3, 2008 at 6:20 PM, Arjan van de Ven
> > <arjan@infradead.org> wrote:
> > > On Tue, 03 Jun 2008 17:41:09 -0700
> > > Alok Kataria <akataria@vmware.com> wrote:
> > >
> > >> On X86 platform we can use the value of cpu_khz computed during tsc
> > >> calibration to calculate the loops_per_jiffy value. Its very
> > >> important to keep the error in lpj values to minimum as any error
> > >> in that may result in kernel panic in check_timer.
> > >> In virtualization environment on a highly overloaded host, the
> > >> guest delay calibration may sometimes result in errors beyond the
> > >> ~50% that timer_irq_works can handle, resulting in the guest
> > >> panicking.
> > > \
> > >
> > > can you guarantee that the rate tsc ticks at is the same as the
> > > current CPU frequency? Answer: You can't....
> > >
> >
> > I think at the boot time atleast we can assume that, no ?
> 
> Nope, absolutely not.
> 1) The rate TSC ticks may or may not be the maximum frequency (usually
> is, but no guarantee)
> 2) The BIOS might not boot your system at the maximum frequency (think
> "laptop on battery")... that's really up to the BIOS.
> 

So then, how about using the tsc_khz (tsc frequency) for this
calculation. Atleast for the boot processor the lpj value can be derived
from the tsc frequency.
So insted of using lpj_tsc for all cpu's we can use it just for the boot
processor.

> >
> > > sadly we do need to calibrate this...
> > >
> > > In addition, clearly you can have different cpus in a system run at
> > > a different rate (both in terms of cpu_khz and, independently, in
> > > terms of tsc rate)
> > >
> >
> > Again yes at run time frequency's may change but they shouldn't at
> > boottime. AFAIK, i don't think there are X86 MP systems with
> > asymmetric cpus i.e. systems with different
> > base frequencies. If thats not true then there sure is a problem.
> 
> there's nothing that guarantees this. (Well maybe Dell's website does
> because they want to sell you 2 expensive cpus rather than 1 cheap 1
> expensive one ;-)

Agreed so we might not be able to use it for other cpus's. 
Is there a way to get the cpu frequency of the processor that we are
bringing up, i see that there is cpufreq_quick_get but this would be
initialized very late in the boot process.  

If there is a way we can check if the cpu being brought up is same as
the last one and then we can skip the delay calibration, something like
what ia64 does.

Thanks,
Alok

Re: [RFC PATCH] x86:Use cpu_khz for loops_per_jiffy calculation

[Alok Kataria]

Hi Arjan,

I have modified the patch to use the pre-calculated value only for the
boot processor. 

Please have a look.
Patch is on top of today's git.

--
On X86 platform we can use the value of tsc_khz computed during tsc calibration
to calculate the loops_per_jiffy value. Its very important to keep the error in
lpj values to minimum as any error in that may result in kernel panic in
check_timer. 
In virtualization environment, On a highly overloaded host the guest delay
calibration may sometimes result in errors beyond the ~50% that timer_irq_works
can handle, resulting in the guest panicking.

Does some formating changes to lpj_setup code to now have a single printk to
print the bogomips value.

We do this only for the boot processor because the AP's can have different
base frequencies or the BIOS might boot a AP at a different frequency.

Signed-off-by: Alok N Kataria <akataria@vmware.com>

Index: linux-2.6/arch/x86/kernel/time_64.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/time_64.c	2008-06-09 10:19:20.000000000 -0700
+++ linux-2.6/arch/x86/kernel/time_64.c	2008-06-19 17:22:53.000000000 -0700
@@ -123,6 +123,8 @@
 		(boot_cpu_data.x86_vendor == X86_VENDOR_AMD))
 		cpu_khz = calculate_cpu_khz();
 
+	lpj_tsc = ((unsigned long)tsc_khz * 1000)/HZ;
+
 	if (unsynchronized_tsc())
 		mark_tsc_unstable("TSCs unsynchronized");
 
Index: linux-2.6/include/linux/delay.h
===================================================================
--- linux-2.6.orig/include/linux/delay.h	2008-06-09 10:19:20.000000000 -0700
+++ linux-2.6/include/linux/delay.h	2008-06-19 17:22:28.000000000 -0700
@@ -41,6 +41,7 @@
 #define ndelay(x) ndelay(x)
 #endif
 
+extern unsigned long lpj_tsc;
 void calibrate_delay(void);
 void msleep(unsigned int msecs);
 unsigned long msleep_interruptible(unsigned int msecs);
Index: linux-2.6/init/calibrate.c
===================================================================
--- linux-2.6.orig/init/calibrate.c	2008-06-09 10:19:20.000000000 -0700
+++ linux-2.6/init/calibrate.c	2008-06-19 18:21:12.000000000 -0700
@@ -8,7 +8,9 @@
 #include <linux/delay.h>
 #include <linux/init.h>
 #include <linux/timex.h>
+#include <linux/smp.h>
 
+unsigned long lpj_tsc;
 unsigned long preset_lpj;
 static int __init lpj_setup(char *str)
 {
@@ -108,6 +110,10 @@
  * This is the number of bits of precision for the loops_per_jiffy.  Each
  * bit takes on average 1.5/HZ seconds.  This (like the original) is a little
  * better than 1%
+ * For the boot cpu we can skip the delay calibration and assign it a value
+ * calculated based on the tsc frequency.
+ * For the rest of the CPUs we cannot assume that the tsc frequency is same as
+ * the cpu frequency, hence do the calibration for those.
  */
 #define LPS_PREC 8
 
@@ -118,16 +124,15 @@
 
 	if (preset_lpj) {
 		loops_per_jiffy = preset_lpj;
-		printk("Calibrating delay loop (skipped)... "
-			"%lu.%02lu BogoMIPS preset\n",
-			loops_per_jiffy/(500000/HZ),
-			(loops_per_jiffy/(5000/HZ)) % 100);
+		printk(KERN_DEBUG "Calibrating delay loop skipped, "
+				"using preset value.. ");
+	} else if ((smp_processor_id() == 0) && lpj_tsc) {
+		loops_per_jiffy = lpj_tsc;
+		printk(KERN_DEBUG "Calibrating delay loop skipped, "
+				"using value calculated from tsc.. ");
 	} else if ((loops_per_jiffy = calibrate_delay_direct()) != 0) {
-		printk("Calibrating delay using timer specific routine.. ");
-		printk("%lu.%02lu BogoMIPS (lpj=%lu)\n",
-			loops_per_jiffy/(500000/HZ),
-			(loops_per_jiffy/(5000/HZ)) % 100,
-			loops_per_jiffy);
+		printk(KERN_DEBUG "Calibrating delay using timer "
+				 "specific routine.. ");
 	} else {
 		loops_per_jiffy = (1<<12);
 
@@ -161,12 +166,8 @@
 			if (jiffies != ticks)	/* longer than 1 tick */
 				loops_per_jiffy &= ~loopbit;
 		}
-
-		/* Round the value and print it */
-		printk("%lu.%02lu BogoMIPS (lpj=%lu)\n",
-			loops_per_jiffy/(500000/HZ),
-			(loops_per_jiffy/(5000/HZ)) % 100,
-			loops_per_jiffy);
 	}
-
+	printk(KERN_DEBUG "%lu.%02lu BogoMIPS (lpj=%lu)\n",
+			loops_per_jiffy/(500000/HZ),
+			(loops_per_jiffy/(5000/HZ)) % 100, loops_per_jiffy);
 }
Index: linux-2.6/arch/x86/kernel/tsc_32.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/tsc_32.c	2008-06-09 10:19:20.000000000 -0700
+++ linux-2.6/arch/x86/kernel/tsc_32.c	2008-06-19 17:23:42.000000000 -0700
@@ -401,6 +401,7 @@
 void __init tsc_init(void)
 {
 	int cpu;
+	u64 lpj;
 
 	if (!cpu_has_tsc || tsc_disabled) {
 		/* Disable the TSC in case of !cpu_has_tsc */
@@ -421,6 +422,10 @@
 		return;
 	}
 
+	lpj = ((u64)tsc_khz * 1000);
+	do_div(lpj, HZ);
+	lpj_tsc = lpj;
+
 	printk("Detected %lu.%03lu MHz processor.\n",
 				(unsigned long)cpu_khz / 1000,
 				(unsigned long)cpu_khz % 1000);

Re: [RFC PATCH] x86:Use cpu_khz for loops_per_jiffy calculation

[Ingo Molnar]

* Alok Kataria <akataria@vmware.com> wrote:

>  		loops_per_jiffy = preset_lpj;
> -		printk("Calibrating delay loop (skipped)... "
> -			"%lu.%02lu BogoMIPS preset\n",
> -			loops_per_jiffy/(500000/HZ),
> -			(loops_per_jiffy/(5000/HZ)) % 100);
> +		printk(KERN_DEBUG "Calibrating delay loop skipped, "
> +				"using preset value.. ");

i dont think the message should be eliminated from default logs via 
making it KERN_DEBUG - this message is a common pattern people watch out 
for and it does give an indication about various sorts of 
timing/performance trouble.

also, if you break a line like hat i'd suggest to do it like this:

> +		printk(KERN_DEBUG
> +		  "Calibrating delay loop skipped, using preset value.. ");

so that the string remains on a single line.

	Ingo

Re: [RFC PATCH] x86:Use cpu_khz for loops_per_jiffy calculation

[Alok Kataria]

Ok, I have changed the printks to KERN_INFO. 

--
On X86 platform we can use the value of tsc_khz computed during tsc calibration
to calculate the loops_per_jiffy value. Its very important to keep the error in
lpj values to minimum as any error in that may result in kernel panic in
check_timer. 
In virtualization environment, On a highly overloaded host the guest delay
calibration may sometimes result in errors beyond the ~50% that timer_irq_works
can handle, resulting in the guest panicking.

Does some formating changes to lpj_setup code to now have a single printk to
print the bogomips value.

We do this only for the boot processor because the AP's can have different
base frequencies or the BIOS might boot a AP at a different frequency.

Signed-off-by: Alok N Kataria <akataria@vmware.com>

Index: linux-2.6/arch/x86/kernel/time_64.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/time_64.c	2008-06-09 10:19:20.000000000 -0700
+++ linux-2.6/arch/x86/kernel/time_64.c	2008-06-19 17:22:53.000000000 -0700
@@ -123,6 +123,8 @@
 		(boot_cpu_data.x86_vendor == X86_VENDOR_AMD))
 		cpu_khz = calculate_cpu_khz();
 
+	lpj_tsc = ((unsigned long)tsc_khz * 1000)/HZ;
+
 	if (unsynchronized_tsc())
 		mark_tsc_unstable("TSCs unsynchronized");
 
Index: linux-2.6/include/linux/delay.h
===================================================================
--- linux-2.6.orig/include/linux/delay.h	2008-06-09 10:19:20.000000000 -0700
+++ linux-2.6/include/linux/delay.h	2008-06-19 17:22:28.000000000 -0700
@@ -41,6 +41,7 @@
 #define ndelay(x) ndelay(x)
 #endif
 
+extern unsigned long lpj_tsc;
 void calibrate_delay(void);
 void msleep(unsigned int msecs);
 unsigned long msleep_interruptible(unsigned int msecs);
Index: linux-2.6/init/calibrate.c
===================================================================
--- linux-2.6.orig/init/calibrate.c	2008-06-09 10:19:20.000000000 -0700
+++ linux-2.6/init/calibrate.c	2008-06-20 14:16:27.000000000 -0700
@@ -8,7 +8,9 @@
 #include <linux/delay.h>
 #include <linux/init.h>
 #include <linux/timex.h>
+#include <linux/smp.h>
 
+unsigned long lpj_tsc;
 unsigned long preset_lpj;
 static int __init lpj_setup(char *str)
 {
@@ -108,6 +110,10 @@
  * This is the number of bits of precision for the loops_per_jiffy.  Each
  * bit takes on average 1.5/HZ seconds.  This (like the original) is a little
  * better than 1%
+ * For the boot cpu we can skip the delay calibration and assign it a value
+ * calculated based on the tsc frequency.
+ * For the rest of the CPUs we cannot assume that the tsc frequency is same as
+ * the cpu frequency, hence do the calibration for those.
  */
 #define LPS_PREC 8
 
@@ -118,20 +124,20 @@
 
 	if (preset_lpj) {
 		loops_per_jiffy = preset_lpj;
-		printk("Calibrating delay loop (skipped)... "
-			"%lu.%02lu BogoMIPS preset\n",
-			loops_per_jiffy/(500000/HZ),
-			(loops_per_jiffy/(5000/HZ)) % 100);
+		printk(KERN_INFO
+			"Calibrating delay loop (skipped) preset value.. ");
+	} else if ((smp_processor_id() == 0) && lpj_tsc) {
+		loops_per_jiffy = lpj_tsc;
+		printk(KERN_INFO
+			"Calibrating delay loop (skipped), "
+			"using tsc calculated value.. ");
 	} else if ((loops_per_jiffy = calibrate_delay_direct()) != 0) {
-		printk("Calibrating delay using timer specific routine.. ");
-		printk("%lu.%02lu BogoMIPS (lpj=%lu)\n",
-			loops_per_jiffy/(500000/HZ),
-			(loops_per_jiffy/(5000/HZ)) % 100,
-			loops_per_jiffy);
+		printk(KERN_INFO
+			"Calibrating delay using timer specific routine.. ");
 	} else {
 		loops_per_jiffy = (1<<12);
 
-		printk(KERN_DEBUG "Calibrating delay loop... ");
+		printk(KERN_INFO "Calibrating delay loop... ");
 		while ((loops_per_jiffy <<= 1) != 0) {
 			/* wait for "start of" clock tick */
 			ticks = jiffies;
@@ -161,12 +167,8 @@
 			if (jiffies != ticks)	/* longer than 1 tick */
 				loops_per_jiffy &= ~loopbit;
 		}
-
-		/* Round the value and print it */
-		printk("%lu.%02lu BogoMIPS (lpj=%lu)\n",
-			loops_per_jiffy/(500000/HZ),
-			(loops_per_jiffy/(5000/HZ)) % 100,
-			loops_per_jiffy);
 	}
-
+	printk(KERN_INFO "%lu.%02lu BogoMIPS (lpj=%lu)\n",
+			loops_per_jiffy/(500000/HZ),
+			(loops_per_jiffy/(5000/HZ)) % 100, loops_per_jiffy);
 }
Index: linux-2.6/arch/x86/kernel/tsc_32.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/tsc_32.c	2008-06-09 10:19:20.000000000 -0700
+++ linux-2.6/arch/x86/kernel/tsc_32.c	2008-06-19 17:23:42.000000000 -0700
@@ -401,6 +401,7 @@
 void __init tsc_init(void)
 {
 	int cpu;
+	u64 lpj;
 
 	if (!cpu_has_tsc || tsc_disabled) {
 		/* Disable the TSC in case of !cpu_has_tsc */
@@ -421,6 +422,10 @@
 		return;
 	}
 
+	lpj = ((u64)tsc_khz * 1000);
+	do_div(lpj, HZ);
+	lpj_tsc = lpj;
+
 	printk("Detected %lu.%03lu MHz processor.\n",
 				(unsigned long)cpu_khz / 1000,
 				(unsigned long)cpu_khz % 1000);

Re: [RFC PATCH] x86:Use cpu_khz for loops_per_jiffy calculation

[Ingo Molnar]

* Alok Kataria <akataria@vmware.com> wrote:

> Ok, I have changed the printks to KERN_INFO. 
> 
> On X86 platform we can use the value of tsc_khz computed during tsc 
> calibration to calculate the loops_per_jiffy value. Its very important 
> to keep the error in lpj values to minimum as any error in that may 
> result in kernel panic in check_timer. In virtualization environment, 
> On a highly overloaded host the guest delay calibration may sometimes 
> result in errors beyond the ~50% that timer_irq_works can handle, 
> resulting in the guest panicking.
> 
> Does some formating changes to lpj_setup code to now have a single 
> printk to print the bogomips value.
> 
> We do this only for the boot processor because the AP's can have 
> different base frequencies or the BIOS might boot a AP at a different 
> frequency.

applied to tip/x86/delay - thanks Alok.

could you check whether tip/master (which now includes your changes as 
well) works as expected in your test environment? I had to do a conflict 
resolution in tsc_32.c, i hope i got it right. You can pick it up via:

  http://people.redhat.com/mingo/tip.git/README

	Ingo

Re: [RFC PATCH] x86:Use cpu_khz for loops_per_jiffy calculation

[Ingo Molnar]

* Alok Kataria <akataria@vmware.com> wrote:

> +	lpj = ((u64)tsc_khz * 1000);
> +	do_div(lpj, HZ);
> +	lpj_tsc = lpj;

this needed the fix below.

but there's another problem as well: why are generic files 
(init/calibrate.c and include/linux/delay.h) using something that is 
named in an x86-specific way - lpj_tsc ? (TSC is an x86 concept)

	Ingo

------------>
commit 5cd5a41ea6f4363b03156e2208dd0d2266f0d67d
Author: Ingo Molnar <mingo@elte.hu>
Date:   Tue Jun 24 01:19:49 2008 +0200

    x86: fix "x86: use cpu_khz for loops_per_jiffy calculation"
    
    fix:
    
    arch/x86/kernel/tsc_32.c: In function ‘tsc_init':
    arch/x86/kernel/tsc_32.c:421: error: ‘lpj_tsc' undeclared (first use in this function)
    arch/x86/kernel/tsc_32.c:421: error: (Each undeclared identifier is reported only once
    arch/x86/kernel/tsc_32.c:421: error: for each function it appears in.)
    
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

diff --git a/arch/x86/kernel/tsc_32.c b/arch/x86/kernel/tsc_32.c
index 4adac0d..bfb9193 100644
--- a/arch/x86/kernel/tsc_32.c
+++ b/arch/x86/kernel/tsc_32.c
@@ -1,6 +1,7 @@
 #include <linux/sched.h>
 #include <linux/clocksource.h>
 #include <linux/workqueue.h>
+#include <linux/delay.h>
 #include <linux/cpufreq.h>
 #include <linux/jiffies.h>
 #include <linux/init.h>

Re: [RFC PATCH] x86:Use cpu_khz for loops_per_jiffy calculation

[Alok Kataria]

On Mon, 2008-06-23 at 16:21 -0700, Ingo Molnar wrote:
> * Alok Kataria <akataria@vmware.com> wrote:
> 
> > +     lpj = ((u64)tsc_khz * 1000);
> > +     do_div(lpj, HZ);
> > +     lpj_tsc = lpj;
> 
> this needed the fix below.
> 
> but there's another problem as well: why are generic files
> (init/calibrate.c and include/linux/delay.h) using something that is
> named in an x86-specific way - lpj_tsc ? (TSC is an x86 concept)
> 

calibrate_delay_direct was using some variables with "tsc" as the prefix
(tsc_rate_min/max) ...so i thought of using lpj_tsc. And also IMO,
lpj_tsc explains how is this variable initialized. But thinking about
it, maybe we should rename it to "lpj_timer" ?

Also, i still haven't got to testing today's tip tree in my environment,
will let you know as soon as i have done it. 

Thanks,
Alok
>         Ingo
> 
> ------------>
> commit 5cd5a41ea6f4363b03156e2208dd0d2266f0d67d
> Author: Ingo Molnar <mingo@elte.hu>
> Date:   Tue Jun 24 01:19:49 2008 +0200
> 
>     x86: fix "x86: use cpu_khz for loops_per_jiffy calculation"
> 
>     fix:
> 
>     arch/x86/kernel/tsc_32.c: In function ‘tsc_init':
>     arch/x86/kernel/tsc_32.c:421: error: ‘lpj_tsc' undeclared (first use in this function)
>     arch/x86/kernel/tsc_32.c:421: error: (Each undeclared identifier is reported only once
>     arch/x86/kernel/tsc_32.c:421: error: for each function it appears in.)
> 
>     Signed-off-by: Ingo Molnar <mingo@elte.hu>
> 
> diff --git a/arch/x86/kernel/tsc_32.c b/arch/x86/kernel/tsc_32.c
> index 4adac0d..bfb9193 100644
> --- a/arch/x86/kernel/tsc_32.c
> +++ b/arch/x86/kernel/tsc_32.c
> @@ -1,6 +1,7 @@
>  #include <linux/sched.h>
>  #include <linux/clocksource.h>
>  #include <linux/workqueue.h>
> +#include <linux/delay.h>
>  #include <linux/cpufreq.h>
>  #include <linux/jiffies.h>
>  #include <linux/init.h>

Re: [RFC PATCH] x86:Use cpu_khz for loops_per_jiffy calculation

[Ingo Molnar]

* Alok Kataria <akataria@vmware.com> wrote:

> > but there's another problem as well: why are generic files 
> > (init/calibrate.c and include/linux/delay.h) using something that is 
> > named in an x86-specific way - lpj_tsc ? (TSC is an x86 concept)
> 
> calibrate_delay_direct was using some variables with "tsc" as the 
> prefix (tsc_rate_min/max) ...so i thought of using lpj_tsc. And also 
> IMO, lpj_tsc explains how is this variable initialized. But thinking 
> about it, maybe we should rename it to "lpj_timer" ?

ok. But instead of 'lpj_timer' i'd suggest to use something like 
'lpj_fine' - as this really is about finegrained measurements.

I'd suggest a delta patch against tip/master that renames all those 
tsc_* variables to fine_*. So tsc_rate_min would become fine_rate_min, 
etc.

	Ingo

Re: [RFC PATCH] x86:Use cpu_khz for loops_per_jiffy calculation

[Alok Kataria]

On Mon, 2008-06-23 at 16:47 -0700, Ingo Molnar wrote:
> * Alok Kataria <akataria@vmware.com> wrote:
> 
> > IMO, lpj_tsc explains how is this variable initialized. But thinking
> > about it, maybe we should rename it to "lpj_timer" ?
> 
> ok. But instead of 'lpj_timer' i'd suggest to use something like
> 'lpj_fine' - as this really is about finegrained measurements.

Ok.
> 
> I'd suggest a delta patch against tip/master that renames all those
> tsc_* variables to fine_*. So tsc_rate_min would become fine_rate_min,
> etc.

Ingo, tsc_rate_min etc are related to the timer rate so calling it
fine_rate_min would be confusing IMO. Instead i call it as
timer_rate_min. 
Below is the patch on tip/master.
Tested on both 32 and 64 bit environment, tree works fine for me. 

--
As suggested by Ingo, remove all references to tsc from init/calibrate.c

TSC is x86 specific, and using tsc in variable names in a generic file should
be avoided. lpj_tsc is now called lpj_fine, since it is related to fine tuning
of lpj value. Also tsc_rate_*  is called timer_rate_*

Signed-off-by: Alok N Kataria <akataria@vmware.com>

Index: linux-x86-tree.git/arch/x86/kernel/time_64.c
===================================================================
--- linux-x86-tree.git.orig/arch/x86/kernel/time_64.c	2008-06-23 17:24:07.000000000 -0700
+++ linux-x86-tree.git/arch/x86/kernel/time_64.c	2008-06-23 17:50:51.000000000 -0700
@@ -123,7 +123,7 @@
 		(boot_cpu_data.x86_vendor == X86_VENDOR_AMD))
 		cpu_khz = calculate_cpu_khz();
 
-	lpj_tsc = ((unsigned long)tsc_khz * 1000)/HZ;
+	lpj_fine = ((unsigned long)tsc_khz * 1000)/HZ;
 
 	if (unsynchronized_tsc())
 		mark_tsc_unstable("TSCs unsynchronized");
Index: linux-x86-tree.git/arch/x86/kernel/tsc_32.c
===================================================================
--- linux-x86-tree.git.orig/arch/x86/kernel/tsc_32.c	2008-06-23 17:24:07.000000000 -0700
+++ linux-x86-tree.git/arch/x86/kernel/tsc_32.c	2008-06-23 17:50:58.000000000 -0700
@@ -419,7 +419,7 @@
 
 	lpj = ((u64)tsc_khz * 1000);
 	do_div(lpj, HZ);
-	lpj_tsc = lpj;
+	lpj_fine = lpj;
 
 	/* now allow native_sched_clock() to use rdtsc */
 	tsc_disabled = 0;
Index: linux-x86-tree.git/include/linux/delay.h
===================================================================
--- linux-x86-tree.git.orig/include/linux/delay.h	2008-06-23 17:24:26.000000000 -0700
+++ linux-x86-tree.git/include/linux/delay.h	2008-06-23 17:51:08.000000000 -0700
@@ -41,7 +41,7 @@
 #define ndelay(x) ndelay(x)
 #endif
 
-extern unsigned long lpj_tsc;
+extern unsigned long lpj_fine;
 void calibrate_delay(void);
 void msleep(unsigned int msecs);
 unsigned long msleep_interruptible(unsigned int msecs);
Index: linux-x86-tree.git/init/calibrate.c
===================================================================
--- linux-x86-tree.git.orig/init/calibrate.c	2008-06-23 17:24:26.000000000 -0700
+++ linux-x86-tree.git/init/calibrate.c	2008-06-23 18:05:38.000000000 -0700
@@ -10,7 +10,7 @@
 #include <linux/timex.h>
 #include <linux/smp.h>
 
-unsigned long lpj_tsc;
+unsigned long lpj_fine;
 unsigned long preset_lpj;
 static int __init lpj_setup(char *str)
 {
@@ -35,9 +35,9 @@
 	unsigned long pre_start, start, post_start;
 	unsigned long pre_end, end, post_end;
 	unsigned long start_jiffies;
-	unsigned long tsc_rate_min, tsc_rate_max;
-	unsigned long good_tsc_sum = 0;
-	unsigned long good_tsc_count = 0;
+	unsigned long timer_rate_min, timer_rate_max;
+	unsigned long good_timer_sum = 0;
+	unsigned long good_timer_count = 0;
 	int i;
 
 	if (read_current_timer(&pre_start) < 0 )
@@ -81,22 +81,24 @@
 		}
 		read_current_timer(&post_end);
 
-		tsc_rate_max = (post_end - pre_start) / DELAY_CALIBRATION_TICKS;
-		tsc_rate_min = (pre_end - post_start) / DELAY_CALIBRATION_TICKS;
+		timer_rate_max = (post_end - pre_start) /
+					DELAY_CALIBRATION_TICKS;
+		timer_rate_min = (pre_end - post_start) /
+					DELAY_CALIBRATION_TICKS;
 
 		/*
-	 	 * If the upper limit and lower limit of the tsc_rate is
+		 * If the upper limit and lower limit of the timer_rate is
 		 * >= 12.5% apart, redo calibration.
 		 */
 		if (pre_start != 0 && pre_end != 0 &&
-		    (tsc_rate_max - tsc_rate_min) < (tsc_rate_max >> 3)) {
-			good_tsc_count++;
-			good_tsc_sum += tsc_rate_max;
+		    (timer_rate_max - timer_rate_min) < (timer_rate_max >> 3)) {
+			good_timer_count++;
+			good_timer_sum += timer_rate_max;
 		}
 	}
 
-	if (good_tsc_count)
-		return (good_tsc_sum/good_tsc_count);
+	if (good_timer_count)
+		return (good_timer_sum/good_timer_count);
 
 	printk(KERN_WARNING "calibrate_delay_direct() failed to get a good "
 	       "estimate for loops_per_jiffy.\nProbably due to long platform interrupts. Consider using \"lpj=\" boot option.\n");
@@ -111,8 +113,8 @@
  * bit takes on average 1.5/HZ seconds.  This (like the original) is a little
  * better than 1%
  * For the boot cpu we can skip the delay calibration and assign it a value
- * calculated based on the tsc frequency.
- * For the rest of the CPUs we cannot assume that the tsc frequency is same as
+ * calculated based on the timer frequency.
+ * For the rest of the CPUs we cannot assume that the timer frequency is same as
  * the cpu frequency, hence do the calibration for those.
  */
 #define LPS_PREC 8
@@ -126,11 +128,11 @@
 		loops_per_jiffy = preset_lpj;
 		printk(KERN_INFO
 			"Calibrating delay loop (skipped) preset value.. ");
-	} else if ((smp_processor_id() == 0) && lpj_tsc) {
-		loops_per_jiffy = lpj_tsc;
+	} else if ((smp_processor_id() == 0) && lpj_fine) {
+		loops_per_jiffy = lpj_fine;
 		printk(KERN_INFO
 			"Calibrating delay loop (skipped), "
-			"using tsc calculated value.. ");
+			"value calculated using timer frequency.. ");
 	} else if ((loops_per_jiffy = calibrate_delay_direct()) != 0) {
 		printk(KERN_INFO
 			"Calibrating delay using timer specific routine.. ");

Re: [RFC PATCH] x86:Use cpu_khz for loops_per_jiffy calculation

[Ingo Molnar]

* Alok Kataria <akataria@vmware.com> wrote:

> On Mon, 2008-06-23 at 16:47 -0700, Ingo Molnar wrote:
> > * Alok Kataria <akataria@vmware.com> wrote:
> > 
> > > IMO, lpj_tsc explains how is this variable initialized. But thinking
> > > about it, maybe we should rename it to "lpj_timer" ?
> > 
> > ok. But instead of 'lpj_timer' i'd suggest to use something like
> > 'lpj_fine' - as this really is about finegrained measurements.
> 
> Ok.
> > 
> > I'd suggest a delta patch against tip/master that renames all those
> > tsc_* variables to fine_*. So tsc_rate_min would become fine_rate_min,
> > etc.
> 
> Ingo, tsc_rate_min etc are related to the timer rate so calling it 
> fine_rate_min would be confusing IMO. Instead i call it as 
> timer_rate_min. Below is the patch on tip/master. Tested on both 32 
> and 64 bit environment, tree works fine for me.

applied to tip/x86/delay - thanks Alok.

	Ingo

Re: [RFC PATCH] x86:Use cpu_khz for loops_per_jiffy calculation

[Pavel Machek]

Hi!

> On X86 platform we can use the value of tsc_khz computed during tsc calibration
> to calculate the loops_per_jiffy value. Its very important to keep the error in
> lpj values to minimum as any error in that may result in kernel panic in
> check_timer. 
> In virtualization environment, On a highly overloaded host the guest delay
> calibration may sometimes result in errors beyond the ~50% that timer_irq_works
> can handle, resulting in the guest panicking.

How did you adress 'khz has nothing to do with loops per jiffie'
comment?

Some cpus can do loop in cycle , some need two cycles, some need half.

								Pavel

> @@ -421,6 +422,10 @@
>  		return;
>  	}
>  
> +	lpj = ((u64)tsc_khz * 1000);
> +	do_div(lpj, HZ);
> +	lpj_tsc = lpj;
> +
>  	printk("Detected %lu.%03lu MHz processor.\n",
>  				(unsigned long)cpu_khz / 1000,
>  				(unsigned long)cpu_khz % 1000);
> 


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [RFC PATCH] x86:Use cpu_khz for loops_per_jiffy calculation

[Alok Kataria]

On Tue, 2008-06-24 at 10:57 -0700, Pavel Machek wrote:
> Hi!
> 
> > On X86 platform we can use the value of tsc_khz computed during tsc calibration
> > to calculate the loops_per_jiffy value. Its very important to keep the error in
> > lpj values to minimum as any error in that may result in kernel panic in
> > check_timer.
> > In virtualization environment, On a highly overloaded host the guest delay
> > calibration may sometimes result in errors beyond the ~50% that timer_irq_works
> > can handle, resulting in the guest panicking.
> 
> How did you adress 'khz has nothing to do with loops per jiffie'
> comment?
> 
> Some cpus can do loop in cycle , some need two cycles, some need half.

Hi Pavel, 

When you say loops per jiffies has nothing to do with khz, by khz you
mean the cpu frequency, right ?

AFAIU in calibrate_delay_direct too we measure the amount by which timer
has ticked until DELAY_CALIBRATION_TICKS amount of jiffies has passed.
So IMO the code there too assumes that there is one loop per timer
cycle ?

If that's not the case then i fail to understand how does the current
code figures out how many loops occur in a cycle ?

Thanks,
Alok

> 
>                                                                 Pavel
> 
> > @@ -421,6 +422,10 @@
> >               return;
> >       }
> >
> > +     lpj = ((u64)tsc_khz * 1000);
> > +     do_div(lpj, HZ);
> > +     lpj_tsc = lpj;
> > +
> >       printk("Detected %lu.%03lu MHz processor.\n",
> >                               (unsigned long)cpu_khz / 1000,
> >                               (unsigned long)cpu_khz % 1000);
> >
> 
> 
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [RFC PATCH] x86:Use cpu_khz for loops_per_jiffy calculation

[Pavel Machek]

On Thu 2008-06-26 10:20:31, Alok Kataria wrote:
> On Tue, 2008-06-24 at 10:57 -0700, Pavel Machek wrote:
> > Hi!
> > 
> > > On X86 platform we can use the value of tsc_khz computed during tsc calibration
> > > to calculate the loops_per_jiffy value. Its very important to keep the error in
> > > lpj values to minimum as any error in that may result in kernel panic in
> > > check_timer.
> > > In virtualization environment, On a highly overloaded host the guest delay
> > > calibration may sometimes result in errors beyond the ~50% that timer_irq_works
> > > can handle, resulting in the guest panicking.
> > 
> > How did you adress 'khz has nothing to do with loops per jiffie'
> > comment?
> > 
> > Some cpus can do loop in cycle , some need two cycles, some need half.
> 
> Hi Pavel, 
> 
> When you say loops per jiffies has nothing to do with khz, by khz you
> mean the cpu frequency, right ?

Yes.

> AFAIU in calibrate_delay_direct too we measure the amount by which timer
> has ticked until DELAY_CALIBRATION_TICKS amount of jiffies has passed.
> So IMO the code there too assumes that there is one loop per timer
> cycle ?

On my machine, it reports:

delay using timer specific routine.. 3661.98 BogoMIPS (lpj=7323971)
...
Detected 1828.828 MHz processor.

(/proc/cpuinfo)
model name	: Genuine Intel(R) CPU           T2400  @ 1.83GHz
...
cpu MHz		: 1000.000
...
bogomips	: 3657.54

So you'd break it by setting lpj (aka bogomips) to cpu_khz, right?

							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [RFC PATCH] x86:Use cpu_khz for loops_per_jiffy calculation

[Alok Kataria]

On Thu, 2008-06-26 at 10:35 -0700, Pavel Machek wrote:
> On Thu 2008-06-26 10:20:31, Alok Kataria wrote:
> > On Tue, 2008-06-24 at 10:57 -0700, Pavel Machek wrote:
> > > Hi!
> > >
> > > > On X86 platform we can use the value of tsc_khz computed during tsc calibration
> > > > to calculate the loops_per_jiffy value. Its very important to keep the error in
> > > > lpj values to minimum as any error in that may result in kernel panic in
> > > > check_timer.
> > > > In virtualization environment, On a highly overloaded host the guest delay
> > > > calibration may sometimes result in errors beyond the ~50% that timer_irq_works
> > > > can handle, resulting in the guest panicking.
> > >
> > > How did you adress 'khz has nothing to do with loops per jiffie'
> > > comment?
> > >
> > > Some cpus can do loop in cycle , some need two cycles, some need half.
> >
> > Hi Pavel,
> >
> > When you say loops per jiffies has nothing to do with khz, by khz you
> > mean the cpu frequency, right ?
> 
> Yes.
> 
> > AFAIU in calibrate_delay_direct too we measure the amount by which timer
> > has ticked until DELAY_CALIBRATION_TICKS amount of jiffies has passed.
> > So IMO the code there too assumes that there is one loop per timer
> > cycle ?
> 
> On my machine, it reports:
> 
> delay using timer specific routine.. 3661.98 BogoMIPS (lpj=7323971)
> ...
> Detected 1828.828 MHz processor.
> 
> (/proc/cpuinfo)
> model name      : Genuine Intel(R) CPU           T2400  @ 1.83GHz
> ...
> cpu MHz         : 1000.000
How is it 1000 here ? shouldn't this be 1830.xx
> ...
> bogomips        : 3657.54
> 
> So you'd break it by setting lpj (aka bogomips) to cpu_khz, right?

We are not setting it to cpu_khz but to tsc_khz, i am assuming that in
this case tsc_khz will be different than cpu_khz. Can you please mail me
the full dmesg log.

Thanks,
Alok
> 
>                                                         Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [RFC PATCH] x86:Use cpu_khz for loops_per_jiffy calculation

[Pavel Machek]

Hi!

> > > > Some cpus can do loop in cycle , some need two cycles, some need half.
> > >
> > > Hi Pavel,
> > >
> > > When you say loops per jiffies has nothing to do with khz, by khz you
> > > mean the cpu frequency, right ?
> > 
> > Yes.
> > 
> > > AFAIU in calibrate_delay_direct too we measure the amount by which timer
> > > has ticked until DELAY_CALIBRATION_TICKS amount of jiffies has passed.
> > > So IMO the code there too assumes that there is one loop per timer
> > > cycle ?
> > 
> > On my machine, it reports:
> > 
> > delay using timer specific routine.. 3661.98 BogoMIPS (lpj=7323971)
> > ...
> > Detected 1828.828 MHz processor.
> > 
> > (/proc/cpuinfo)
> > model name      : Genuine Intel(R) CPU           T2400  @ 1.83GHz
> > ...
> > cpu MHz         : 1000.000
> How is it 1000 here ? shouldn't this be 1830.xx

cpufreq effect, I believe.

> > bogomips        : 3657.54
> > 
> > So you'd break it by setting lpj (aka bogomips) to cpu_khz, right?
> 
> We are not setting it to cpu_khz but to tsc_khz, i am assuming that in
> this case tsc_khz will be different than cpu_khz. Can you please mail me
> the full dmesg log.

Yes, but neither cpu_khz nor tsc_khz will be 3657 bogoMips, right?

Anyway, here are my boot messages.
								Pavel

Linux version 2.6.26-rc8 (pavel@amd) (gcc version 4.1.3 20071209 (prerelease) (Debian 4.1.2-18)) #310 SMP Thu Jun 26 00:09:08 CEST 2008
PAT disabled. Not yet verified on this CPU type.
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f000 (usable)
 BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000d2000 - 00000000000d4000 (reserved)
 BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000007f6d0000 (usable)
 BIOS-e820: 000000007f6d0000 - 000000007f6df000 (ACPI data)
 BIOS-e820: 000000007f6df000 - 000000007f700000 (ACPI NVS)
 BIOS-e820: 000000007f700000 - 0000000080000000 (reserved)
 BIOS-e820: 00000000f0000000 - 00000000f4000000 (reserved)
 BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
 BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved)
 BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved)
 BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
 BIOS-e820: 00000000ff800000 - 0000000100000000 (reserved)
1142MB HIGHMEM available.
896MB LOWMEM available.
found SMP MP-table at [c00f67f0] 000f67f0
Entering add_active_range(0, 0, 521936) 0 entries of 256 used
Zone PFN ranges:
  DMA             0 ->     4096
  Normal       4096 ->   229376
  HighMem    229376 ->   521936
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0:        0 ->   521936
On node 0 totalpages: 521936
  DMA zone: 32 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 4064 pages, LIFO batch:0
  Normal zone: 1760 pages used for memmap
  Normal zone: 223520 pages, LIFO batch:31
  HighMem zone: 2286 pages used for memmap
  HighMem zone: 290274 pages, LIFO batch:31
  Movable zone: 0 pages used for memmap
DMI present.
ACPI: RSDP 000F67C0, 0024 (r2 LENOVO)
ACPI: XSDT 7F6D191C, 0084 (r1 LENOVO TP-7B        2140  LTP        0)
ACPI: FACP 7F6D1A00, 00F4 (r3 LENOVO TP-7B        2140 LNVO        1)
ACPI Warning (tbfadt-0442): Optional field "Gpe1Block" has zero address or length: 000000000000102C/0 [20080321]
ACPI: DSDT 7F6D1D90, CFB9 (r1 LENOVO TP-7B        2140 MSFT  100000E)
ACPI: FACS 7F6F4000, 0040
ACPI: SSDT 7F6D1BB4, 01DC (r1 LENOVO TP-7B        2140 MSFT  100000E)
ACPI: ECDT 7F6DED49, 0052 (r1 LENOVO TP-7B        2140 LNVO        1)
ACPI: TCPA 7F6DED9B, 0032 (r2 LENOVO TP-7B        2140 LNVO        1)
ACPI: APIC 7F6DEDCD, 0068 (r1 LENOVO TP-7B        2140 LNVO        1)
ACPI: MCFG 7F6DEE35, 003C (r1 LENOVO TP-7B        2140 LNVO        1)
ACPI: HPET 7F6DEE71, 0038 (r1 LENOVO TP-7B        2140 LNVO        1)
ACPI: BOOT 7F6DEFD8, 0028 (r1 LENOVO TP-7B        2140  LTP        1)
ACPI: SSDT 7F6F2645, 025F (r1 LENOVO TP-7B        2140 INTL 20050513)
ACPI: SSDT 7F6F28A4, 00A6 (r1 LENOVO TP-7B        2140 INTL 20050513)
ACPI: SSDT 7F6F294A, 04F7 (r1 LENOVO TP-7B        2140 INTL 20050513)
ACPI: SSDT 7F6F2E41, 01D8 (r1 LENOVO TP-7B        2140 INTL 20050513)
ACPI: PM-Timer IO Port: 0x1008
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
ACPI: HPET id: 0x8086a201 base: 0xfed00000
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 88000000 (gap: 80000000:70000000)
PM: Registered nosave memory: 000000000009f000 - 00000000000a0000
PM: Registered nosave memory: 00000000000a0000 - 00000000000d2000
PM: Registered nosave memory: 00000000000d2000 - 00000000000d4000
PM: Registered nosave memory: 00000000000d4000 - 00000000000dc000
PM: Registered nosave memory: 00000000000dc000 - 0000000000100000
SMP: Allowing 2 CPUs, 0 hotplug CPUs
PERCPU: Allocating 37800 bytes of per cpu data
NR_CPUS: 2, nr_cpu_ids: 2
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 517858
Kernel command line: root=/dev/sda4 resume=/dev/sda1 psmouse.psmouse_proto=imps psmouse_proto=imps psmouse.proto=imps vga=791 init=/tmp/swsusp-init acpi_sleep=s3_bios,s3_mode no_console_suspend
Unknown boot option `psmouse.psmouse_proto=imps': ignoring
mapped APIC to ffffb000 (fee00000)
mapped IOAPIC to ffffa000 (fec00000)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 16384 bytes)
Extended CMOS year: 2000
Detected 1828.828 MHz processor.
Console: colour dummy device 80x25
console [tty0] enabled
Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
... MAX_LOCKDEP_SUBCLASSES:    8
... MAX_LOCK_DEPTH:          48
... MAX_LOCKDEP_KEYS:        2048
... CLASSHASH_SIZE:           1024
... MAX_LOCKDEP_ENTRIES:     8192
... MAX_LOCKDEP_CHAINS:      16384
... CHAINHASH_SIZE:          8192
 memory used by lock dependency info: 992 kB
 per task-struct memory footprint: 1920 bytes
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 2059076k/2087744k available (5319k kernel code, 27508k reserved, 2455k data, 320k init, 1170240k highmem)
virtual kernel memory layout:
    fixmap  : 0xfff7f000 - 0xfffff000   ( 512 kB)
    pkmap   : 0xff800000 - 0xffc00000   (4096 kB)
    vmalloc : 0xf8800000 - 0xff7fe000   ( 111 MB)
    lowmem  : 0xc0000000 - 0xf8000000   ( 896 MB)
      .init : 0xc099f000 - 0xc09ef000   ( 320 kB)
      .data : 0xc0731da6 - 0xc0997a08   (2455 kB)
      .text : 0xc0200000 - 0xc0731da6   (5319 kB)
Checking if this processor honours the WP bit even in supervisor mode...Ok.
CPA: page pool initialized 32 of 32 pages preallocated
hpet clockevent registered
Calibrating delay using timer specific routine.. 3661.98 BogoMIPS (lpj=7323971)
Mount-cache hash table entries: 512
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 2048K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
using mwait in idle threads.
Checking 'hlt' instruction... OK.
ACPI: Core revision 20080321
Parsing all Control Methods:
Table [DSDT](id 0001) - 1592 Objects with 69 Devices 429 Methods 28 Regions
Parsing all Control Methods:
Table [SSDT](id 0002) - 11 Objects with 0 Devices 7 Methods 0 Regions
Parsing all Control Methods:
Table [SSDT](id 0003) - 7 Objects with 0 Devices 3 Methods 0 Regions
Parsing all Control Methods:
Table [SSDT](id 0004) - 4 Objects with 0 Devices 3 Methods 0 Regions
Parsing all Control Methods:
Table [SSDT](id 0005) - 14 Objects with 0 Devices 5 Methods 0 Regions
Parsing all Control Methods:
Table [SSDT](id 0006) - 14 Objects with 1 Devices 2 Methods 0 Regions
 tbxface-0598 [00] tb_load_namespace     : ACPI Tables successfully acquired
evxfevnt-0091 [00] enable                : Transition to ACPI mode successful
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
CPU0: Intel Genuine Intel(R) CPU           T2400  @ 1.83GHz stepping 08
lockdep: fixing up alternatives.
Booting processor 1/1 ip 6000
Initializing CPU#1
Calibrating delay using timer specific routine.. 3657.54 BogoMIPS (lpj=7315090)
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 2048K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 1
CPU1: Intel Genuine Intel(R) CPU           T2400  @ 1.83GHz stepping 08
checking TSC synchronization [CPU#0 -> CPU#1]:
Measured 580008 cycles TSC warp between CPUs, turning off TSC clock.
Marking TSC unstable due to: check_tsc_sync_source failed.
Brought up 2 CPUs
Total of 2 processors activated (7319.53 BogoMIPS).
CPU0 attaching sched-domain:
 domain 0: span 0-1
  groups: 0 1
CPU1 attaching sched-domain:
 domain 0: span 0-1
  groups: 1 0
net_namespace: 548 bytes
NET: Registered protocol family 16
ACPI: ACPI Dock Station Driver
ACPI: \_SB_.PCI0.IDE0.PRIM.MSTR: found ejectable bay
ACPI: \_SB_.PCI0.IDE0.PRIM.MSTR: Adding notify handler
ACPI: \_SB_.PCI0.IDE0.PRIM.MSTR: Is dependent on dock

ACPI: Bay [\_SB_.PCI0.IDE0.PRIM.MSTR] Added
ACPI: bus type pci registered
PCI: MCFG configuration 0: base f0000000 segment 0 buses 0 - 63
PCI: MCFG area at f0000000 reserved in E820
PCI: Using MMCONFIG for extended config space
PCI: Using configuration type 1 for base access
Setting up standard PCI resources
evgpeblk-0956 [00] ev_create_gpe_block   : GPE 00 to 1F [_GPE] 4 regs on int 0x9
ACPI: EC: EC description table is found, configuring boot EC
Completing Region/Field/Buffer/Package initialization:........................................................................................................................................................................................................................................................................
Initialized 28/28 Regions 126/126 Fields 54/54 Buffers 56/56 Packages (1651 nodes)
Initializing Device/Processor/Thermal objects by executing _INI methods:...<6>ACPI: EC: non-query interrupt received, switching to interrupt mode
....
Executed 7 _INI methods requiring 2 _STA executions (examined 76 objects)
evgpeblk-1052 [00] ev_initialize_gpe_bloc: Found 8 Wake, Enabled 2 Runtime GPEs in this block
ACPI: Interpreter enabled
ACPI: (supports S0 S3 S4 S5)
ACPI: Using IOAPIC for interrupt routing
ACPI: EC: GPE = 0x1c, I/O: command/status = 0x66, data = 0x62
ACPI: EC: driver started in interrupt mode
ACPI: PCI Root Bridge [PCI0] (0000:00)
pci 0000:00:1f.0: quirk: region 1000-107f claimed by ICH6 ACPI/GPIO/TCO
pci 0000:00:1f.0: quirk: region 1180-11bf claimed by ICH6 GPIO
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP1._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP2._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP3._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 *11)
ACPI: Power Resource [PUBS] (on)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp: PnP ACPI: found 12 devices
ACPI: ACPI bus type pnp unregistered
SCSI subsystem initialized
libata version 3.00 loaded.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Using ACPI for IRQ routing
Bluetooth: Core ver 2.11
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
ACPI: RTC can wake from S4
system 00:00: iomem range 0x0-0x9ffff could not be reserved
system 00:00: iomem range 0xc0000-0xc3fff could not be reserved
system 00:00: iomem range 0xc4000-0xc7fff could not be reserved
system 00:00: iomem range 0xc8000-0xcbfff has been reserved
system 00:00: iomem range 0xcc000-0xcffff could not be reserved
system 00:00: iomem range 0xd0000-0xd3fff could not be reserved
system 00:00: iomem range 0xdc000-0xdffff has been reserved
system 00:00: iomem range 0xe0000-0xe3fff has been reserved
system 00:00: iomem range 0xe4000-0xe7fff has been reserved
system 00:00: iomem range 0xe8000-0xebfff has been reserved
system 00:00: iomem range 0xec000-0xeffff has been reserved
system 00:00: iomem range 0xf0000-0xfffff could not be reserved
system 00:00: iomem range 0x100000-0x7fffffff could not be reserved
system 00:00: iomem range 0xfec00000-0xfed3ffff could not be reserved
system 00:00: iomem range 0xfed41000-0xffffffff could not be reserved
system 00:02: ioport range 0x164e-0x164f has been reserved
system 00:02: ioport range 0x1000-0x107f has been reserved
system 00:02: ioport range 0x1180-0x11bf has been reserved
system 00:02: ioport range 0x800-0x80f has been reserved
system 00:02: ioport range 0x15e0-0x15ef has been reserved
system 00:02: ioport range 0x1600-0x165f could not be reserved
system 00:02: iomem range 0xf0000000-0xf3ffffff could not be reserved
system 00:02: iomem range 0xfed1c000-0xfed1ffff could not be reserved
system 00:02: iomem range 0xfed14000-0xfed17fff could not be reserved
system 00:02: iomem range 0xfed18000-0xfed18fff could not be reserved
system 00:02: iomem range 0xfed19000-0xfed19fff could not be reserved
PCI: Bridge: 0000:00:1c.0
  IO window: 2000-2fff
  MEM window: 0xee000000-0xee0fffff
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:1c.1
  IO window: 3000-4fff
  MEM window: 0xec000000-0xedffffff
  PREFETCH window: 0x00000000e4000000-0x00000000e40fffff
PCI: Bridge: 0000:00:1c.2
  IO window: 5000-6fff
  MEM window: 0xe8000000-0xe9ffffff
  PREFETCH window: 0x00000000e4100000-0x00000000e41fffff
PCI: Bridge: 0000:00:1c.3
  IO window: 7000-8fff
  MEM window: 0xea000000-0xebffffff
  PREFETCH window: 0x00000000e4200000-0x00000000e42fffff
PCI: Bus 22, cardbus bridge: 0000:15:00.0
  IO window: 0x00009000-0x000090ff
  IO window: 0x00009400-0x000094ff
  PREFETCH window: 0xe0000000-0xe3ffffff
  MEM window: 0x88000000-0x8bffffff
PCI: Bridge: 0000:00:1e.0
  IO window: 9000-cfff
  MEM window: 0xe4300000-0xe7ffffff
  PREFETCH window: 0x00000000e0000000-0x00000000e3ffffff
PCI: Setting latency timer of device 0000:00:1c.0 to 64
PCI: Setting latency timer of device 0000:00:1c.1 to 64
PCI: Setting latency timer of device 0000:00:1c.2 to 64
PCI: Setting latency timer of device 0000:00:1c.3 to 64
pci 0000:00:1e.0: enabling device (0005 -> 0007)
PCI: Setting latency timer of device 0000:00:1e.0 to 64
PCI: Setting latency timer of device 0000:15:00.0 to 64
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 9, 2097152 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
NET: Registered protocol family 1
Simple Boot Flag at 0x35 set to 0x1
highmem bounce pool size: 64 pages
NTFS driver 2.1.29 [Flags: R/O DEBUG].
JFFS2 version 2.2. (NAND) Š 2001-2006 Red Hat, Inc.
fuse init (API version 7.9)
msgmni has been set to 1737
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
pci 0000:00:02.0: Boot video device
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
acpiphp_ibm: ibm_acpiphp_init: acpi_walk_namespace failed
vesafb: framebuffer at 0xd0000000, mapped to 0xf8880000, using 3072k, total 7872k
vesafb: mode is 1024x768x16, linelength=2048, pages=4
vesafb: scrolling: redraw
vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
Console: switching to colour frame buffer device 102x42
fb0: VESA VGA frame buffer device
ACPI: AC Adapter [AC] (on-line)
ACPI: Battery Slot [BAT0] (battery present)
input: Power Button (FF) as /class/input/input0
ACPI: Power Button (FF) [PWRF]
input: Lid Switch as /class/input/input1
ACPI: Lid Switch [LID]
input: Sleep Button (CM) as /class/input/input2
ACPI: Sleep Button (CM) [SLPB]
ACPI: SSDT 7F6F1D26, 0240 (r1  PmRef  Cpu0Ist      100 INTL 20050513)
Parsing all Control Methods:
Table [SSDT](id 0025) - 6 Objects with 0 Devices 4 Methods 0 Regions
ACPI: SSDT 7F6F1FEB, 065A (r1  PmRef  Cpu0Cst      100 INTL 20050513)
Parsing all Control Methods:
Table [SSDT](id 0026) - 13 Objects with 0 Devices 1 Methods 0 Regions
ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
ACPI: ACPI0007:00 is registered as cooling_device0
ACPI: Processor [CPU0] (supports 8 throttling states)
ACPI: SSDT 7F6F1C5E, 00C8 (r1  PmRef  Cpu1Ist      100 INTL 20050513)
Parsing all Control Methods:
Table [SSDT](id 0030) - 4 Objects with 0 Devices 4 Methods 0 Regions
ACPI: SSDT 7F6F1F66, 0085 (r1  PmRef  Cpu1Cst      100 INTL 20050513)
Parsing all Control Methods:
Table [SSDT](id 0031) - 1 Objects with 0 Devices 1 Methods 0 Regions
ACPI: CPU1 (power states: C1[C1] C2[C2] C3[C3])
ACPI: ACPI0007:01 is registered as cooling_device1
ACPI: Processor [CPU1] (supports 8 throttling states)
ACPI: LNXTHERM:01 is registered as thermal_zone0
ACPI: Thermal Zone [THM0] (61 C)
ACPI: LNXTHERM:02 is registered as thermal_zone1
ACPI: Thermal Zone [THM1] (62 C)
lp: driver loaded but no devices found
Non-volatile memory driver v1.2
intel_rng: FWH not detected
cs5535_gpio: DIVIL not found
Linux agpgart interface v0.103
agpgart: Detected an Intel 945GM Chipset.
agpgart: Detected 7932K stolen memory.
agpgart: AGP aperture is 256M @ 0xd0000000
[drm] Initialized drm 1.1.0 20060810
PCI: Setting latency timer of device 0000:00:02.0 to 64
[drm] Initialized i915 1.6.0 20060119 on minor 0
intelfb: Framebuffer driver for Intel(R) 830M/845G/852GM/855GM/865G/915G/915GM/945G/945GM/965G/965GM chipsets
intelfb: Version 0.9.5
intelfb: Cannot reserve FB region.
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a NS16550A
floppy0: no floppy controllers found
loop: module loaded
thinkpad_acpi: ThinkPad ACPI Extras v0.20
thinkpad_acpi: http://ibm-acpi.sf.net/
thinkpad_acpi: ThinkPad BIOS 7BETD3WW (2.14 ), EC 7BHT40WW-1.13
thinkpad_acpi: Lenovo ThinkPad X60, model 17097HU
thinkpad_acpi: radio switch found; radios are enabled
thinkpad_acpi: This ThinkPad has standard ACPI backlight brightness control, supported by the ACPI video driver
thinkpad_acpi: Disabling thinkpad-acpi brightness events by default...
Registered led device: tpacpi::thinklight
Registered led device: tpacpi::power
Registered led device: tpacpi:orange:batt
Registered led device: tpacpi:green:batt
Registered led device: tpacpi::dock_active
Registered led device: tpacpi::bay_active
Registered led device: tpacpi::dock_batt
Registered led device: tpacpi::unknown_led
Registered led device: tpacpi::standby
thinkpad_acpi: Lenovo BIOS switched to ACPI backlight control mode
thinkpad_acpi: standard ACPI backlight interface available, not loading native one...
input: ThinkPad Extra Buttons as /class/input/input3
e1000e: Intel(R) PRO/1000 Network Driver - 0.3.3.3-k2
e1000e: Copyright (c) 1999-2008 Intel Corporation.
e1000e 0000:02:00.0: Disabling L1 ASPM
PCI: Setting latency timer of device 0000:02:00.0 to 64
eth0: (PCI Express:2.5GB/s:Width x1) 00:16:d3:25:19:04
eth0: Intel(R) PRO/1000 Network Connection
eth0: MAC: 2, PHY: 2, PBA No: 005302-003
pcnet32.c:v1.35 21.Apr.2008 tsbogend@alpha.franken.de
e100: Intel(R) PRO/100 Network Driver, 3.5.23-k4-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
PPP BSD Compression module registered
SLIP: version 0.8.4-NET3.019-NEWTTY (dynamic channels, max=256).
CSLIP: code copyright 1989 Regents of the University of California.
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
usbcore: registered new interface driver catc
catc: v2.8 CATC EL1210A NetMate USB Ethernet driver
usbcore: registered new interface driver asix
usbcore: registered new interface driver cdc_ether
usbcore: registered new interface driver net1080
usbcore: registered new interface driver cdc_subset
usbcore: registered new interface driver zaurus
Broadcom 43xx driver loaded [ Features: PL, Firmware-ID: FW13 ]
usbcore: registered new interface driver zd1211rw
usbcore: registered new interface driver zd1201
[w35und]driver init
usbcore: registered new interface driver w35und
iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, 1.2.26kds
iwl3945: Copyright(c) 2003-2008 Intel Corporation
PCI: Setting latency timer of device 0000:03:00.0 to 64
iwl3945: Detected Intel Wireless WiFi Link 3945ABG
iwl3945: Tunable channels: 11 802.11bg, 13 802.11a channels
phy0: Selected rate control algorithm 'iwl-3945-rs'
ACPI: PCI interrupt for device 0000:03:00.0 disabled
Linux video capture interface: v2.00
Uniform Multi-Platform E-IDE driver
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH7: IDE controller (0x8086:0x27df rev 0x02) at  PCI slot 0000:00:1f.1
ICH7: not 100% native mode: will probe irqs later
ICH7: IDE port disabled
    ide0: BM-DMA at 0x1810-0x1817
Probing IDE interface ide0...
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide_generic: please use "probe_mask=0x3f" module parameter for probing all legacy ISA IDE ports
ide_generic: I/O resource 0x1F0-0x1F7 not free.
ide_generic: I/O resource 0x170-0x177 not free.
ahci 0000:00:1f.2: version 3.0
ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 4 ports 1.5 Gbps 0x1 impl SATA mode
ahci 0000:00:1f.2: flags: 64bit ncq pm led clo pio slum part 
PCI: Setting latency timer of device 0000:00:1f.2 to 64
scsi0 : ahci
ahci: autosuspend disabled
scsi1 : ahci
ahci: autosuspend disabled
scsi2 : ahci
ahci: autosuspend disabled
scsi3 : ahci
ahci: autosuspend disabled
ata1: SATA max UDMA/133 abar m1024@0xee444400 port 0xee444500 irq 16
ata2: DUMMY
ata3: DUMMY
ata4: DUMMY
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ACPI cmd ef/02:00:00:00:00:a0 succeeded
ata1.00: ACPI cmd f5/00:00:00:00:00:a0 filtered out
ata1.00: ACPI cmd ef/10:03:00:00:00:a0 succeeded
ata1.00: ATA-7: HTS541060G9SA00, MB3IC60H, max UDMA/100
ata1.00: 117210240 sectors, multi 16: LBA48 
ata1.00: ACPI cmd ef/02:00:00:00:00:a0 succeeded
ata1.00: ACPI cmd f5/00:00:00:00:00:a0 filtered out
ata1.00: ACPI cmd ef/10:03:00:00:00:a0 succeeded
ata1.00: configured for UDMA/100
ata1.00: configured for UDMA/100
ata1: EH complete
scsi 0:0:0:0: Direct-Access     ATA      HTS541060G9SA00  MB3I PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 117210240 512-byte hardware sectors (60012 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 0:0:0:0: [sda] 117210240 512-byte hardware sectors (60012 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sda: sda1 sda2 sda4
sd 0:0:0:0: [sda] Attached SCSI disk
sd 0:0:0:0: Attached scsi generic sg0 type 0
Yenta: CardBus bridge found at 0000:15:00.0 [17aa:201c]
Yenta: ISA IRQ mask 0x0cb8, PCI irq 16
Socket status: 30000006
pcmcia: parent PCI bridge I/O window: 0x9000 - 0xcfff
pcmcia: parent PCI bridge Memory window: 0xe4300000 - 0xe7ffffff
pcmcia: parent PCI bridge Memory window: 0xe0000000 - 0xe3ffffff
PCI: Setting latency timer of device 0000:00:1d.7 to 64
ehci_hcd 0000:00:1d.7: EHCI Host Controller
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:1d.7: debug port 1
PCI: cache line size of 32 is not supported by device 0000:00:1d.7
ehci_hcd 0000:00:1d.7: irq 19, io mem 0xee444000
ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 8 ports detected
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: EHCI Host Controller
usb usb1: Manufacturer: Linux 2.6.26-rc8 ehci_hcd
usb usb1: SerialNumber: 0000:00:1d.7
ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
USB Universal Host Controller Interface driver v3.0
PCI: Setting latency timer of device 0000:00:1d.0 to 64
uhci_hcd 0000:00:1d.0: UHCI Host Controller
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:1d.0: irq 16, io base 0x00001820
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
usb usb2: New USB device found, idVendor=1d6b, idProduct=0001
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: UHCI Host Controller
usb usb2: Manufacturer: Linux 2.6.26-rc8 uhci_hcd
usb usb2: SerialNumber: 0000:00:1d.0
PCI: Setting latency timer of device 0000:00:1d.1 to 64
uhci_hcd 0000:00:1d.1: UHCI Host Controller
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:1d.1: irq 17, io base 0x00001840
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
usb usb3: New USB device found, idVendor=1d6b, idProduct=0001
usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb3: Product: UHCI Host Controller
usb usb3: Manufacturer: Linux 2.6.26-rc8 uhci_hcd
usb usb3: SerialNumber: 0000:00:1d.1
PCI: Setting latency timer of device 0000:00:1d.2 to 64
uhci_hcd 0000:00:1d.2: UHCI Host Controller
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
uhci_hcd 0000:00:1d.2: irq 18, io base 0x00001860
usb usb4: configuration #1 chosen from 1 choice
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
usb usb4: New USB device found, idVendor=1d6b, idProduct=0001
usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb4: Product: UHCI Host Controller
usb usb4: Manufacturer: Linux 2.6.26-rc8 uhci_hcd
usb usb4: SerialNumber: 0000:00:1d.2
PCI: Setting latency timer of device 0000:00:1d.3 to 64
uhci_hcd 0000:00:1d.3: UHCI Host Controller
uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 5
uhci_hcd 0000:00:1d.3: irq 19, io base 0x00001880
usb usb5: configuration #1 chosen from 1 choice
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 2 ports detected
usb usb5: New USB device found, idVendor=1d6b, idProduct=0001
usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb5: Product: UHCI Host Controller
usb usb5: Manufacturer: Linux 2.6.26-rc8 uhci_hcd
usb usb5: SerialNumber: 0000:00:1d.3
usb 5-1: new full speed USB device using uhci_hcd and address 2
usb 5-1: configuration #1 chosen from 1 choice
usb 5-1: New USB device found, idVendor=0a5c, idProduct=2110
usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 5-1: Product: BCM2045B
usb 5-1: Manufacturer: Broadcom Corp
usb 5-2: new full speed USB device using uhci_hcd and address 3
usb 5-2: configuration #1 chosen from 1 choice
usb 5-2: New USB device found, idVendor=0483, idProduct=2016
usb 5-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 5-2: Product: Biometric Coprocessor
usb 5-2: Manufacturer: STMicroelectronics
usbcore: registered new interface driver cdc_acm
cdc_acm: v0.26:USB Abstract Control Model driver for USB modems and ISDN adapters
usbcore: registered new interface driver usblp
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU] at 0x60,0x64 irq 1,12
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard as /class/input/input4
input: PC Speaker as /class/input/input5
input: PS/2 Generic Mouse as /class/input/input6
rtc_cmos 00:07: rtc core: registered rtc_cmos as rtc0
rtc0: alarms up to one month, y3k
md: raid0 personality registered for level 0
md: raid1 personality registered for level 1
device-mapper: ioctl: 4.13.0-ioctl (2007-10-18) initialised: dm-devel@redhat.com
Bluetooth: HCI UART driver ver 2.2
Bluetooth: HCI H4 protocol initialized
Bluetooth: HCI BCSP protocol initialized
Bluetooth: Generic Bluetooth USB driver ver 0.1
usbcore: registered new interface driver btusb
EDAC MC: Ver: 2.1.0 Jun 25 2008
cpuidle: using governor ladder
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
sdhci: SDHCI controller found at 0000:15:00.2 [1180:0822] (rev 18)
mmc0: Will use DMA mode even though HW doesn't fully claim to support it.
PCI: Setting latency timer of device 0000:15:00.2 to 64
Registered led device: mmc0
mmc0: SDHCI at 0xe4301800 irq 18 DMA
ricoh-mmc: Ricoh MMC Controller disabling driver
ricoh-mmc: Copyright(c) Philip Langdale
usbcore: registered new interface driver usbhid
usbhid: v2.6:USB HID core driver
Advanced Linux Sound Architecture Driver Version 1.0.16.
hda_intel: probe_mask set to 0x1 for device 17aa:2010
PCI: Setting latency timer of device 0000:00:1b.0 to 64
usbcore: registered new interface driver snd-usb-audio
ALSA device list:
  #0: HDA Intel at 0xee240000 irq 17
nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
ip_tables: (C) 2000-2006 Netfilter Core Team
TCP cubic registered
NET: Registered protocol family 17
Bluetooth: L2CAP ver 2.9
Bluetooth: L2CAP socket layer initialized
Bluetooth: SCO (Voice Link) ver 0.5
Bluetooth: SCO socket layer initialized
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM TTY layer initialized
Bluetooth: RFCOMM ver 1.8
Bluetooth: BNEP (Ethernet Emulation) ver 1.2
Bluetooth: BNEP filters: protocol multicast
Bluetooth: HIDP (Human Interface Emulation) ver 1.2
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
ieee80211: 802.11 data/management/control stack, git-1.1.13
ieee80211: Copyright (C) 2004-2005 Intel Corporation <jketreno@linux.intel.com>
ieee80211_crypt: registered algorithm 'NULL'
ieee80211_crypt: registered algorithm 'WEP'
Installing 9P2000 support
Using IPI No-Shortcut mode
PM: Resume from partition /dev/sda1
PM: Checking hibernation image.
PM: Resume from disk failed.
md: Autodetecting RAID arrays.
md: Scanned 0 and added 0 devices.
md: autorun ...
md: ... autorun DONE.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
debug: unmapping init memory c099f000..c09ef000
Write protecting the kernel text: 5320k
Write protecting the kernel read-only data: 1916k
Failed to execute /tmp/swsusp-init.  Attempting defaults...
EXT3 FS on sda4, internal journal
Adding 987988k swap on /dev/sda1.  Priority:-1 extents:1 across:987988k
kjournald starting.  Commit interval 5 seconds
EXT3 FS on sda2, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
pcmcia: Detected deprecated PCMCIA ioctl usage from process: hwclock.
pcmcia: This interface will soon be removed from the kernel; please expect breakage unless you upgrade to new tools.
pcmcia: see http://www.kernel.org/pub/linux/utils/kernel/pcmcia/pcmcia.html for details.
coda_read_super: Bad mount data
coda_read_super: device index: 0
coda_read_super: rootfid is (01234567.ffffffff.08051a38.00000000)
coda: Unexpected interruption.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [RFC PATCH] x86:Use cpu_khz for loops_per_jiffy calculation

[Alok Kataria]

On Thu, 2008-06-26 at 15:16 -0700, Pavel Machek wrote:
> Hi!
> 
> > > > > Some cpus can do loop in cycle , some need two cycles, some need half.
> > > >
> > > > Hi Pavel,
> > > >
> > > > When you say loops per jiffies has nothing to do with khz, by khz you
> > > > mean the cpu frequency, right ?
> > >
> > > Yes.
> > >
> > > > AFAIU in calibrate_delay_direct too we measure the amount by which timer
> > > > has ticked until DELAY_CALIBRATION_TICKS amount of jiffies has passed.
> > > > So IMO the code there too assumes that there is one loop per timer
> > > > cycle ?
> > >
> > > On my machine, it reports:
> > >
> > > delay using timer specific routine.. 3661.98 BogoMIPS (lpj=7323971)
> > > ...
> > > Detected 1828.828 MHz processor.
> > >
> > > (/proc/cpuinfo)
> > > model name      : Genuine Intel(R) CPU           T2400  @ 1.83GHz
> > > ...
> > > cpu MHz         : 1000.000
> > How is it 1000 here ? shouldn't this be 1830.xx
> 
> cpufreq effect, I believe.
> 
> > > bogomips        : 3657.54
> > >
> > > So you'd break it by setting lpj (aka bogomips) to cpu_khz, right?
> >
> > We are not setting it to cpu_khz but to tsc_khz, i am assuming that in
> > this case tsc_khz will be different than cpu_khz. Can you please mail me
> > the full dmesg log.
> 
> Yes, but neither cpu_khz nor tsc_khz will be 3657 bogoMips, right?

Hi Pavel,

Thanks for the dmesg. The HZ value that you are using on this system is
250, right ?

If you note the calculations
> +     lpj = ((u64)tsc_khz * 1000);
> +     do_div(lpj, HZ);

We are dividing by HZ over here. So you are right in saying that tsc_khz
wont be equal to bogoMips but lpj_fine will surely be computed correct
since we do consider the HZ value.

Please let me know if you still have any doubts.
Or can i safely assume that you will ACK the patch ;-)

Thanks,
Alok



> 
> Anyway, here are my boot messages.
>                                                                 Pavel
> 

Re: [RFC PATCH] x86:Use cpu_khz for loops_per_jiffy calculation

[Pavel Machek]

Hi!

> > > > > AFAIU in calibrate_delay_direct too we measure the amount by which timer
> > > > > has ticked until DELAY_CALIBRATION_TICKS amount of jiffies has passed.
> > > > > So IMO the code there too assumes that there is one loop per timer
> > > > > cycle ?
> > > >
> > > > On my machine, it reports:
> > > >
> > > > delay using timer specific routine.. 3661.98 BogoMIPS (lpj=7323971)
> > > > ...
> > > > Detected 1828.828 MHz processor.
> > > >
> > > > (/proc/cpuinfo)
> > > > model name      : Genuine Intel(R) CPU           T2400  @ 1.83GHz
> > > > ...
> > > > cpu MHz         : 1000.000
> > > How is it 1000 here ? shouldn't this be 1830.xx
> > 
> > cpufreq effect, I believe.
> > 
> > > > bogomips        : 3657.54
> > > >
> > > > So you'd break it by setting lpj (aka bogomips) to cpu_khz, right?
> > >
> > > We are not setting it to cpu_khz but to tsc_khz, i am assuming that in
> > > this case tsc_khz will be different than cpu_khz. Can you please mail me
> > > the full dmesg log.
> > 
> > Yes, but neither cpu_khz nor tsc_khz will be 3657 bogoMips, right?
> 
> Hi Pavel,
> 
> Thanks for the dmesg. The HZ value that you are using on this system is
> 250, right ?
> 
> If you note the calculations
> > +     lpj = ((u64)tsc_khz * 1000);
> > +     do_div(lpj, HZ);
> 
> We are dividing by HZ over here. So you are right in saying that tsc_khz
> wont be equal to bogoMips but lpj_fine will surely be computed correct
> since we do consider the HZ value.

Ok.

> Please let me know if you still have any doubts.
> Or can i safely assume that you will ACK the patch ;-)

Well, I'm not expert-enough in this subsystem (nor comfortable enough
with your code) to ACK it, sorry.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [RFC PATCH] x86:Use cpu_khz for loops_per_jiffy calculation

[Pavel Machek]

Hi!

> @@ -123,6 +123,8 @@
>  		(boot_cpu_data.x86_vendor == X86_VENDOR_AMD))
>  		cpu_khz = calculate_cpu_khz();
>  
> +	lpj_tsc = ((unsigned long)cpu_khz * 1000)/HZ;
> +

No. Some cpus do one loop per tick, some do two loops per tick, and
there are probably weird cpus, too.

							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [RFC PATCH] x86:Use cpu_khz for loops_per_jiffy calculation

[Ingo Molnar]

* Alok Kataria <akataria@vmware.com> wrote:

> --- linux-2.6.orig/arch/x86/kernel/tsc_32.c	2008-05-27 12:28:16.000000000 -0700
> +++ linux-2.6/arch/x86/kernel/tsc_32.c	2008-06-03 17:28:46.000000000 -0700
> @@ -401,6 +401,7 @@
>  void __init tsc_init(void)
>  {
>  	int cpu;
> +	u64 lpj;
>  
>  	if (!cpu_has_tsc || tsc_disabled) {
>  		/* Disable the TSC in case of !cpu_has_tsc */
> @@ -421,6 +422,10 @@
>  		return;
>  	}
>  
> +	lpj = ((u64)cpu_khz * 1000);
> +	do_div(lpj, HZ);
> +	lpj_tsc = lpj;

that wont work very well as lpj_tsc is not declared.

	Ingo

Re: [RFC PATCH] x86:Use cpu_khz for loops_per_jiffy calculation

[Alok Kataria]

On Mon, 2008-06-09 at 06:11 -0700, Ingo Molnar wrote:
> * Alok Kataria <akataria@vmware.com> wrote:
> 
> > --- linux-2.6.orig/arch/x86/kernel/tsc_32.c   2008-05-27 12:28:16.000000000 -0700
> > +++ linux-2.6/arch/x86/kernel/tsc_32.c        2008-06-03 17:28:46.000000000 -0700
> > @@ -401,6 +401,7 @@
> >  void __init tsc_init(void)
> >  {
> >       int cpu;
> > +     u64 lpj;
> >
> >       if (!cpu_has_tsc || tsc_disabled) {
> >               /* Disable the TSC in case of !cpu_has_tsc */
> > @@ -421,6 +422,10 @@
> >               return;
> >       }
> >
> > +     lpj = ((u64)cpu_khz * 1000);
> > +     do_div(lpj, HZ);
> > +     lpj_tsc = lpj;
> 
> that wont work very well as lpj_tsc is not declared.

lpj_tsc is declared in include/linux/delay.h, and that declaration is
available in tsc_32.c 

I compile tested against current git too and seems fine to me. 

Also this patch is not to be applied to any tree yet, i will make a
different patch which calculates lpj_tsc from tsc_khz instead and use it
only for the boor processor. 
There were some concerns from Arjan and Pavel regarding cpu frequency
being different on different cpus. I was waiting to hear back from them
before sending a new patch.

Let me know your comments on my questions/suggestions from the earlier
post
http://marc.info/?l=linux-kernel&m=121269125317375&w=2


Thanks,
Alok


> 
>         Ingo