All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] Greatly improve TSC calibration using a delayed workqueue
@ 2010-11-06  0:39 John Stultz
  2010-11-07 20:41 ` Andi Kleen
  2010-12-05 11:18 ` [tip:x86/tsc] x86: Improve " tip-bot for John Stultz
  0 siblings, 2 replies; 24+ messages in thread
From: John Stultz @ 2010-11-06  0:39 UTC (permalink / raw)
  To: LKML
  Cc: John Stultz, Thomas Gleixner, Ingo Molnar, Martin Schwidefsky,
	Clark Williams, Andi Kleen

Boot to boot the TSC calibration may vary by quite a large amount.

While normal variance of 50-100ppm can easily be seen, the quick
calibration code only requires 500ppm accuracy, which is the limit
of what NTP can correct for.

This can cause problems for systems being used as NTP servers, as
every time they reboot it can take hours for them to calculate the
new drift error caused by the calibration.

The classic trade-off here is calibration accuracy vs slow boot times,
as during the calibration nothing else can run.

This patch uses a delayed workqueue  to calibrate the TSC over the
period of a second. This allows very accurate calibration (in my
tests only varying by 1khz or 0.4ppm boot to boot). Additionally this
refined calibration step does not block the boot process, and only
delays the TSC clocksoure registration by a few seconds in early boot.

Credit to Andi Kleen who suggested using a timer quite awhile back,
but I dismissed it thinking the timer calibration would be done after
the clocksource was registered (which would break things). Forgive
me for my short-sightedness.

This patch has worked very well in my testing, but TSC hardware is
quite varied so it would probably be good to get some extended
testing, possibly pushing inclusion out to 2.6.39.

Signed-off-by: John Stultz <johnstul@us.ibm.com>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Ingo Molnar <mingo@elte.hu>
CC: Martin Schwidefsky <schwidefsky@de.ibm.com>
CC: Clark Williams <williams@redhat.com>
CC: Andi Kleen <andi@firstfloor.org>
---
 arch/x86/kernel/tsc.c |   69 ++++++++++++++++++++++++++++++++++++++++++++++--
 1 files changed, 66 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 0c40d8b..e88b71e 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -885,7 +885,69 @@ __cpuinit int unsynchronized_tsc(void)
 	return tsc_unstable;
 }
 
-static void __init init_tsc_clocksource(void)
+
+static void calibrate_tsc_work(struct work_struct *work);
+static DECLARE_DELAYED_WORK(tsc_irqwork, calibrate_tsc_work);
+
+static void calibrate_tsc_work(struct work_struct *work)
+{
+	static u64 tsc_start = -1, ref_start;
+	static int hpet;
+	u64 tsc_stop, ref_stop, delta;
+	unsigned long freq;
+
+	/* Don't bother refining TSC on unstable systems */
+	if (check_tsc_unstable())
+		goto out;
+
+	/*
+	 * Since the timer is started early in boot, we may be
+	 * delayed the first time we expire. So set the timer
+	 * again once we know timers are working.
+	 */
+	if (tsc_start == -1) {
+		/*
+		 * Only set hpet once, to avoid mixing hardware
+		 * if the hpet becomes enabled later.
+		 */
+		hpet = is_hpet_enabled();
+		schedule_delayed_work(&tsc_irqwork, HZ);
+		tsc_start = tsc_read_refs(&ref_start, hpet);
+		return;
+	}
+
+	tsc_stop = tsc_read_refs(&ref_stop, hpet);
+
+	/* hpet or pmtimer available ? */
+	if (!hpet && !ref_start && !ref_stop)
+		goto out;
+
+	/* Check, whether the sampling was disturbed by an SMI */
+	if (tsc_start == ULLONG_MAX || tsc_stop == ULLONG_MAX)
+		goto out;
+
+	delta = tsc_stop - tsc_start;
+	delta *= 1000000LL;
+	if (hpet)
+		freq = calc_hpet_ref(delta, ref_start, ref_stop);
+	else
+		freq = calc_pmtimer_ref(delta, ref_start, ref_stop);
+
+	/* Make sure we're within 1% */
+	if (abs(tsc_khz - freq) > tsc_khz/100)
+		goto out;
+
+	tsc_khz = freq;
+	printk(KERN_INFO "Refined TSC clocksource calibration: "
+		"%lu.%03lu MHz.\n", (unsigned long)tsc_khz / 1000,
+					(unsigned long)tsc_khz % 1000);
+
+out:
+	clocksource_register_khz(&clocksource_tsc, tsc_khz);
+}
+
+
+static int __init init_tsc_clocksource(void)
 {
 	if (tsc_clocksource_reliable)
 		clocksource_tsc.flags &= ~CLOCK_SOURCE_MUST_VERIFY;
@@ -894,8 +956,10 @@ static void __init init_tsc_clocksource(void)
 		clocksource_tsc.rating = 0;
 		clocksource_tsc.flags &= ~CLOCK_SOURCE_IS_CONTINUOUS;
 	}
-	clocksource_register_khz(&clocksource_tsc, tsc_khz);
+	schedule_delayed_work(&tsc_irqwork, 0);
+	return 0;
 }
+core_initcall(init_tsc_clocksource);
 
 void __init tsc_init(void)
 {
@@ -949,6 +1013,5 @@ void __init tsc_init(void)
 		mark_tsc_unstable("TSCs unsynchronized");
 
 	check_system_tsc_reliable();
-	init_tsc_clocksource();
 }
 
-- 
1.7.3.2.146.gca209


^ permalink raw reply related	[flat|nested] 24+ messages in thread

* Re: [PATCH] Greatly improve TSC calibration using a delayed workqueue
  2010-11-06  0:39 [PATCH] Greatly improve TSC calibration using a delayed workqueue John Stultz
@ 2010-11-07 20:41 ` Andi Kleen
  2010-11-08 22:04   ` john stultz
  2010-12-05 11:18 ` [tip:x86/tsc] x86: Improve " tip-bot for John Stultz
  1 sibling, 1 reply; 24+ messages in thread
From: Andi Kleen @ 2010-11-07 20:41 UTC (permalink / raw)
  To: John Stultz
  Cc: LKML, Thomas Gleixner, Ingo Molnar, Martin Schwidefsky,
	Clark Williams, Andi Kleen

Hi John,

> +	/*
> +	 * Since the timer is started early in boot, we may be
> +	 * delayed the first time we expire. So set the timer
> +	 * again once we know timers are working.
> +	 */
> +	if (tsc_start == -1) {
> +		/*
> +		 * Only set hpet once, to avoid mixing hardware
> +		 * if the hpet becomes enabled later.
> +		 */
> +		hpet = is_hpet_enabled();
> +		schedule_delayed_work(&tsc_irqwork, HZ);
> +		tsc_start = tsc_read_refs(&ref_start, hpet);
> +		return;
> +	}
> +
> +	tsc_stop = tsc_read_refs(&ref_stop, hpet);

The HPET init code stops, starts the HPET. I think you need some
way to protect against that here, e.g. a variable and rearming the 
timer if it's true.

Another issue may be races against suspend, but that may be too
obscure.

I also worry a bit about NMIs etc. running later during this
and messing up the measurement, but I guess the longer period
makes up for it.

The rest of the patch looks ok to me.

-Andi

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] Greatly improve TSC calibration using a delayed workqueue
  2010-11-07 20:41 ` Andi Kleen
@ 2010-11-08 22:04   ` john stultz
  2010-11-09 13:43     ` Andi Kleen
  0 siblings, 1 reply; 24+ messages in thread
From: john stultz @ 2010-11-08 22:04 UTC (permalink / raw)
  To: Andi Kleen
  Cc: LKML, Thomas Gleixner, Ingo Molnar, Martin Schwidefsky, Clark Williams

On Sun, 2010-11-07 at 21:41 +0100, Andi Kleen wrote:
> Hi John,
> 
> > +	/*
> > +	 * Since the timer is started early in boot, we may be
> > +	 * delayed the first time we expire. So set the timer
> > +	 * again once we know timers are working.
> > +	 */
> > +	if (tsc_start == -1) {
> > +		/*
> > +		 * Only set hpet once, to avoid mixing hardware
> > +		 * if the hpet becomes enabled later.
> > +		 */
> > +		hpet = is_hpet_enabled();
> > +		schedule_delayed_work(&tsc_irqwork, HZ);
> > +		tsc_start = tsc_read_refs(&ref_start, hpet);
> > +		return;
> > +	}
> > +
> > +	tsc_stop = tsc_read_refs(&ref_stop, hpet);
> 
> The HPET init code stops, starts the HPET. I think you need some
> way to protect against that here, e.g. a variable and rearming the 
> timer if it's true.

Interesting. Thanks for pointing that out! Couldn't I just start the
calibration after fs_initcall (when the hpet_late_init runs) to avoid
this as well? 

> Another issue may be races against suspend, but that may be too
> obscure.

Yea, that seems fairly obscure. Basically you'd have to suspend in the
first second as the system came up. In that case the code will throw out
any calibration refinement that's over 1% off of the initial boot
calibration, so I think this is ok trade off.

> I also worry a bit about NMIs etc. running later during this
> and messing up the measurement, but I guess the longer period
> makes up for it.

Yea, the 1 second period should help minimize any disturbance, and
again, this is just a refinement over the existing calibration, so if
its more then 1% off of the boot time fast calibration, we'll throw it
out.

> The rest of the patch looks ok to me.

Thanks for the review!
-john


^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] Greatly improve TSC calibration using a delayed workqueue
  2010-11-08 22:04   ` john stultz
@ 2010-11-09 13:43     ` Andi Kleen
  2010-11-09 21:41       ` john stultz
  0 siblings, 1 reply; 24+ messages in thread
From: Andi Kleen @ 2010-11-09 13:43 UTC (permalink / raw)
  To: john stultz
  Cc: Andi Kleen, LKML, Thomas Gleixner, Ingo Molnar,
	Martin Schwidefsky, Clark Williams

> Interesting. Thanks for pointing that out! Couldn't I just start the
> calibration after fs_initcall (when the hpet_late_init runs) to avoid
> this as well? 

Yes that probably would work.  Or use the barrier infrastructure 
in workqueue.c

> 
> > Another issue may be races against suspend, but that may be too
> > obscure.
> 
> Yea, that seems fairly obscure. Basically you'd have to suspend in the
> first second as the system came up. In that case the code will throw out
> any calibration refinement that's over 1% off of the initial boot
> calibration, so I think this is ok trade off.

It may happen with opportunistic suspend if the system boots very fast.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] Greatly improve TSC calibration using a delayed workqueue
  2010-11-09 13:43     ` Andi Kleen
@ 2010-11-09 21:41       ` john stultz
  2010-11-10 13:47         ` Andi Kleen
  0 siblings, 1 reply; 24+ messages in thread
From: john stultz @ 2010-11-09 21:41 UTC (permalink / raw)
  To: Andi Kleen
  Cc: LKML, Thomas Gleixner, Ingo Molnar, Martin Schwidefsky, Clark Williams

On Tue, 2010-11-09 at 14:43 +0100, Andi Kleen wrote:
> > Interesting. Thanks for pointing that out! Couldn't I just start the
> > calibration after fs_initcall (when the hpet_late_init runs) to avoid
> > this as well? 
> 
> Yes that probably would work.  Or use the barrier infrastructure 
> in workqueue.c
> 
> > 
> > > Another issue may be races against suspend, but that may be too
> > > obscure.
> > 
> > Yea, that seems fairly obscure. Basically you'd have to suspend in the
> > first second as the system came up. In that case the code will throw out
> > any calibration refinement that's over 1% off of the initial boot
> > calibration, so I think this is ok trade off.
> 
> It may happen with opportunistic suspend if the system boots very fast.

Right, but a system using opportunistic suspend will have a hard enough
time keeping close NTP sync on its own given the frequent switching
between the fine-grained ntp adjusted clocksource during run-time and
the coarse non-adjusted RTC/persisitent_clock while suspended.

So I think such a system would be fine it falls back to using just the
boot-calibration for TSC freq rather then the refined calibration freq
calculated by this patch (which will happen automatically if the refined
calibration is off by 1%).

Does that seem like a reasonable tradeoff?

thanks
-john




^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] Greatly improve TSC calibration using a delayed workqueue
  2010-11-09 21:41       ` john stultz
@ 2010-11-10 13:47         ` Andi Kleen
  0 siblings, 0 replies; 24+ messages in thread
From: Andi Kleen @ 2010-11-10 13:47 UTC (permalink / raw)
  To: john stultz
  Cc: Andi Kleen, LKML, Thomas Gleixner, Ingo Molnar,
	Martin Schwidefsky, Clark Williams

On Tue, Nov 09, 2010 at 01:41:40PM -0800, john stultz wrote:
> > It may happen with opportunistic suspend if the system boots very fast.
> 
> Right, but a system using opportunistic suspend will have a hard enough
> time keeping close NTP sync on its own given the frequent switching
> between the fine-grained ntp adjusted clocksource during run-time and
> the coarse non-adjusted RTC/persisitent_clock while suspended.
> 
> So I think such a system would be fine it falls back to using just the
> boot-calibration for TSC freq rather then the refined calibration freq
> calculated by this patch (which will happen automatically if the refined
> calibration is off by 1%).
> 
> Does that seem like a reasonable tradeoff?

Yes it sounds good to me.  Some inaccuracy in this case is fine I guess.
Just major inaccuracy or a crash or hang wouldn't be good.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* [tip:x86/tsc] x86: Improve TSC calibration using a delayed workqueue
  2010-11-06  0:39 [PATCH] Greatly improve TSC calibration using a delayed workqueue John Stultz
  2010-11-07 20:41 ` Andi Kleen
@ 2010-12-05 11:18 ` tip-bot for John Stultz
  2011-01-11  8:13   ` Kirill A. Shutemov
  1 sibling, 1 reply; 24+ messages in thread
From: tip-bot for John Stultz @ 2010-12-05 11:18 UTC (permalink / raw)
  To: linux-tip-commits
  Cc: linux-kernel, hpa, mingo, andi, williams, johnstul, schwidefsky,
	tglx, mingo

Commit-ID:  08ec0c58fb8a05d3191d5cb6f5d6f81adb419798
Gitweb:     http://git.kernel.org/tip/08ec0c58fb8a05d3191d5cb6f5d6f81adb419798
Author:     John Stultz <johnstul@us.ibm.com>
AuthorDate: Tue, 27 Jul 2010 17:00:00 -0700
Committer:  John Stultz <john.stultz@linaro.org>
CommitDate: Thu, 2 Dec 2010 16:48:37 -0800

x86: Improve TSC calibration using a delayed workqueue

Boot to boot the TSC calibration may vary by quite a large amount.

While normal variance of 50-100ppm can easily be seen, the quick
calibration code only requires 500ppm accuracy, which is the limit
of what NTP can correct for.

This can cause problems for systems being used as NTP servers, as
every time they reboot it can take hours for them to calculate the
new drift error caused by the calibration.

The classic trade-off here is calibration accuracy vs slow boot times,
as during the calibration nothing else can run.

This patch uses a delayed workqueue  to calibrate the TSC over the
period of a second. This allows very accurate calibration (in my
tests only varying by 1khz or 0.4ppm boot to boot). Additionally this
refined calibration step does not block the boot process, and only
delays the TSC clocksoure registration by a few seconds in early boot.
If the refined calibration strays 1% from the early boot calibration
value, the system will fall back to already calculated early boot
calibration.

Credit to Andi Kleen who suggested using a timer quite awhile back,
but I dismissed it thinking the timer calibration would be done after
the clocksource was registered (which would break things). Forgive
me for my short-sightedness.

This patch has worked very well in my testing, but TSC hardware is
quite varied so it would probably be good to get some extended
testing, possibly pushing inclusion out to 2.6.39.

Signed-off-by: John Stultz <johnstul@us.ibm.com>
LKML-Reference: <1289003985-29060-1-git-send-email-johnstul@us.ibm.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Ingo Molnar <mingo@elte.hu>
CC: Martin Schwidefsky <schwidefsky@de.ibm.com>
CC: Clark Williams <williams@redhat.com>
CC: Andi Kleen <andi@firstfloor.org>
---
 arch/x86/kernel/tsc.c |   86 +++++++++++++++++++++++++++++++++++++++++++++++--
 1 files changed, 83 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index bb64beb..dc1393e 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -888,7 +888,82 @@ __cpuinit int unsynchronized_tsc(void)
 	return 0;
 }
 
-static void __init init_tsc_clocksource(void)
+
+static void tsc_refine_calibration_work(struct work_struct *work);
+static DECLARE_DELAYED_WORK(tsc_irqwork, tsc_refine_calibration_work);
+/**
+ * tsc_refine_calibration_work - Further refine tsc freq calibration
+ * @work - ignored.
+ *
+ * This functions uses delayed work over a period of a
+ * second to further refine the TSC freq value. Since this is
+ * timer based, instead of loop based, we don't block the boot
+ * process while this longer calibration is done.
+ *
+ * If there are any calibration anomolies (too many SMIs, etc),
+ * or the refined calibration is off by 1% of the fast early
+ * calibration, we throw out the new calibration and use the
+ * early calibration.
+ */
+static void tsc_refine_calibration_work(struct work_struct *work)
+{
+	static u64 tsc_start = -1, ref_start;
+	static int hpet;
+	u64 tsc_stop, ref_stop, delta;
+	unsigned long freq;
+
+	/* Don't bother refining TSC on unstable systems */
+	if (check_tsc_unstable())
+		goto out;
+
+	/*
+	 * Since the work is started early in boot, we may be
+	 * delayed the first time we expire. So set the workqueue
+	 * again once we know timers are working.
+	 */
+	if (tsc_start == -1) {
+		/*
+		 * Only set hpet once, to avoid mixing hardware
+		 * if the hpet becomes enabled later.
+		 */
+		hpet = is_hpet_enabled();
+		schedule_delayed_work(&tsc_irqwork, HZ);
+		tsc_start = tsc_read_refs(&ref_start, hpet);
+		return;
+	}
+
+	tsc_stop = tsc_read_refs(&ref_stop, hpet);
+
+	/* hpet or pmtimer available ? */
+	if (!hpet && !ref_start && !ref_stop)
+		goto out;
+
+	/* Check, whether the sampling was disturbed by an SMI */
+	if (tsc_start == ULLONG_MAX || tsc_stop == ULLONG_MAX)
+		goto out;
+
+	delta = tsc_stop - tsc_start;
+	delta *= 1000000LL;
+	if (hpet)
+		freq = calc_hpet_ref(delta, ref_start, ref_stop);
+	else
+		freq = calc_pmtimer_ref(delta, ref_start, ref_stop);
+
+	/* Make sure we're within 1% */
+	if (abs(tsc_khz - freq) > tsc_khz/100)
+		goto out;
+
+	tsc_khz = freq;
+	printk(KERN_INFO "Refined TSC clocksource calibration: "
+		"%lu.%03lu MHz.\n", (unsigned long)tsc_khz / 1000,
+					(unsigned long)tsc_khz % 1000);
+
+out:
+	clocksource_register_khz(&clocksource_tsc, tsc_khz);
+}
+
+
+static int __init init_tsc_clocksource(void)
 {
 	if (tsc_clocksource_reliable)
 		clocksource_tsc.flags &= ~CLOCK_SOURCE_MUST_VERIFY;
@@ -897,8 +972,14 @@ static void __init init_tsc_clocksource(void)
 		clocksource_tsc.rating = 0;
 		clocksource_tsc.flags &= ~CLOCK_SOURCE_IS_CONTINUOUS;
 	}
-	clocksource_register_khz(&clocksource_tsc, tsc_khz);
+	schedule_delayed_work(&tsc_irqwork, 0);
+	return 0;
 }
+/*
+ * We use device_initcall here, to ensure we run after the hpet
+ * is fully initialized, which may occur at fs_initcall time.
+ */
+device_initcall(init_tsc_clocksource);
 
 void __init tsc_init(void)
 {
@@ -952,6 +1033,5 @@ void __init tsc_init(void)
 		mark_tsc_unstable("TSCs unsynchronized");
 
 	check_system_tsc_reliable();
-	init_tsc_clocksource();
 }
 

^ permalink raw reply related	[flat|nested] 24+ messages in thread

* Re: [tip:x86/tsc] x86: Improve TSC calibration using a delayed workqueue
  2010-12-05 11:18 ` [tip:x86/tsc] x86: Improve " tip-bot for John Stultz
@ 2011-01-11  8:13   ` Kirill A. Shutemov
  2011-01-11  8:26     ` Thomas Gleixner
  0 siblings, 1 reply; 24+ messages in thread
From: Kirill A. Shutemov @ 2011-01-11  8:13 UTC (permalink / raw)
  To: mingo, hpa, linux-kernel, andi, johnstul, williams, schwidefsky,
	tglx, mingo
  Cc: linux-tip-commits

[-- Attachment #1: Type: text/plain, Size: 6235 bytes --]

On Sun, Dec 05, 2010 at 11:18:53AM +0000, tip-bot for John Stultz wrote:
> Commit-ID:  08ec0c58fb8a05d3191d5cb6f5d6f81adb419798
> Gitweb:     http://git.kernel.org/tip/08ec0c58fb8a05d3191d5cb6f5d6f81adb419798
> Author:     John Stultz <johnstul@us.ibm.com>
> AuthorDate: Tue, 27 Jul 2010 17:00:00 -0700
> Committer:  John Stultz <john.stultz@linaro.org>
> CommitDate: Thu, 2 Dec 2010 16:48:37 -0800
> 
> x86: Improve TSC calibration using a delayed workqueue

This commit breaks booting the kernel in qemu with enabled KVM on my machine.
.config attached.

[    0.424013] divide error: 0000 [#1] 
[    0.424013] last sysfs file: 
[    0.424013] Modules linked in:
[    0.424013] 
[    0.424013] Pid: 4, comm: kworker/0:0 Not tainted 2.6.37+ #86 /Bochs
[    0.424013] EIP: 0060:[<c1042a73>] EFLAGS: 00010246 CPU: 0
[    0.424013] EIP is at clocks_calc_mult_shift+0xb3/0xf0
[    0.424013] EAX: 000f4240 EBX: 00000020 ECX: 000f4240 EDX: 00000000
[    0.424013] ESI: 00000000 EDI: 00000000 EBP: c78e3eb4 ESP: c78e3e7c
[    0.424013]  DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
[    0.424013] Process kworker/0:0 (pid: 4, ti=c78e2000 task=c78d1980 task.ti=c78e2000)
[    0.424013] Stack:
[    0.424013]  c78d1ca8 0000024f c1412508 c1412504 00000000 00000000 000f4240 00000000
[    0.424013]  00000020 00000000 000f4240 c14124e0 c78c7000 c1412508 c78e3ed8 c1042aeb
[    0.424013]  000f4240 00001388 000003e8 c1412504 c14124e0 c78c7000 c78e6200 c78e3ee4
[    0.424013] Call Trace:
[    0.424013]  [<c1042aeb>] __clocksource_updatefreq_scale+0x3b/0x60
[    0.424013]  [<c1042b1b>] __clocksource_register_scale+0xb/0x40
[    0.424013]  [<c10074f5>] tsc_refine_calibration_work+0x85/0x2a0
[    0.424013]  [<c1034580>] ? process_one_work+0xe0/0x390
[    0.424013]  [<c10345eb>] process_one_work+0x14b/0x390
[    0.424013]  [<c1034580>] ? process_one_work+0xe0/0x390
[    0.424013]  [<c101cdff>] ? wake_up_process+0xf/0x20
[    0.424013]  [<c1007470>] ? tsc_refine_calibration_work+0x0/0x2a0
[    0.424013]  [<c103536e>] worker_thread+0x10e/0x2a0
[    0.424013]  [<c1035260>] ? worker_thread+0x0/0x2a0
[    0.424013]  [<c1038884>] kthread+0x74/0x80
[    0.424013]  [<c1038810>] ? kthread+0x0/0x80
[    0.424013]  [<c1003096>] kernel_thread_helper+0x6/0x10
[    0.424013] Code: 4d dc 0f 45 d0 0f 45 c6 89 55 f0 8b 55 d8 89 45 ec 01 55 ec 11 4d f0 8b 45 ec 8b 55 f0 89 d1 31 d2 85 c9 89 c6 74 08 89 c8 31 d2 <f7> f7 89 c1 89 f0 31 f6 f7 f7 89 ca 0f b6 4d e8 89 45 c8 89 55 
[    0.424013] EIP: [<c1042a73>] clocks_calc_mult_shift+0xb3/0xf0 SS:ESP 0068:c78e3e7c
[    0.465178] ---[ end trace 6d450e935ee1897c ]---
[    0.465178] BUG: unable to handle kernel paging request at fffffffc
[    0.465178] IP: [<c10389aa>] kthread_data+0xa/0x10
[    0.465178] *pde = 0148e067 *pte = 00000000 
[    0.465178] Oops: 0000 [#2] 
[    0.465178] last sysfs file: 
[    0.465178] Modules linked in:
[    0.465178] 
[    0.465178] Pid: 4, comm: kworker/0:0 Tainted: G      D     2.6.37+ #86 /Bochs
[    0.465178] EIP: 0060:[<c10389aa>] EFLAGS: 00010046 CPU: 0
[    0.465178] EIP is at kthread_data+0xa/0x10
[    0.465178] EAX: 00000000 EBX: 00000000 ECX: c78d1980 EDX: 00000000
[    0.465178] ESI: c1416980 EDI: c78d1980 EBP: c78e3c8c ESP: c78e3c80
[    0.465178]  DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
[    0.465178] Process kworker/0:0 (pid: 4, ti=c78e2000 task=c78d1980 task.ti=c78e2000)
[    0.465178] Stack:
[    0.465178]  c1035541 c78d1ae4 00000001 c78e3d10 c12f5fbf c7fedb00 c78e3cb0 c12eed9d
[    0.465178]  c78d8ac0 c7fedb00 c7ef12f4 c7805380 c78e3cc0 c78e3d10 c78d1980 c78d1980
[    0.465178]  00000046 c140e180 c78d1980 c78d1980 c78d8ac0 c78e3cdc 00000246 c78e3d10
[    0.465178] Call Trace:
[    0.465178]  [<c1035541>] ? wq_worker_sleeping+0x11/0x70
[    0.465178]  [<c12f5fbf>] schedule+0x26f/0x460
[    0.465178]  [<c12eed9d>] ? kmemleak_free+0x2d/0x70
[    0.465178]  [<c1023777>] ? release_task+0x217/0x360
[    0.465178]  [<c102356b>] ? release_task+0xb/0x360
[    0.465178]  [<c104796e>] ? debug_check_no_locks_held+0x1e/0x90
[    0.465178]  [<c1024ec0>] do_exit+0x460/0x660
[    0.465178]  [<c102301a>] ? kmsg_dump+0x10a/0x120
[    0.465178]  [<c100562e>] oops_end+0x6e/0x90
[    0.465178]  [<c100579f>] die+0x4f/0x70
[    0.465178]  [<c1003136>] do_trap+0x96/0xd0
[    0.465178]  [<c1003170>] ? do_divide_error+0x0/0xa0
[    0.465178]  [<c10031f3>] do_divide_error+0x83/0xa0
[    0.465178]  [<c1042a73>] ? clocks_calc_mult_shift+0xb3/0xf0
[    0.465178]  [<c1046055>] ? __lock_acquire.clone.16+0x2f5/0xad0
[    0.465178]  [<c1046055>] ? __lock_acquire.clone.16+0x2f5/0xad0
[    0.465178]  [<c104c54b>] ? __module_text_address+0xb/0x50
[    0.465178]  [<c104fab8>] ? is_module_text_address+0x8/0x10
[    0.465178]  [<c10362b7>] ? __kernel_text_address+0x37/0x60
[    0.465178]  [<c12f8714>] error_code+0x58/0x60
[    0.465178]  [<c12f007b>] ? pci_read_bridge_bases+0x1d9/0x404
[    0.465178]  [<c1003170>] ? do_divide_error+0x0/0xa0
[    0.465178]  [<c1042a73>] ? clocks_calc_mult_shift+0xb3/0xf0
[    0.465178]  [<c1042aeb>] __clocksource_updatefreq_scale+0x3b/0x60
[    0.465178]  [<c1042b1b>] __clocksource_register_scale+0xb/0x40
[    0.465178]  [<c10074f5>] tsc_refine_calibration_work+0x85/0x2a0
[    0.465178]  [<c1034580>] ? process_one_work+0xe0/0x390
[    0.465178]  [<c10345eb>] process_one_work+0x14b/0x390
[    0.465178]  [<c1034580>] ? process_one_work+0xe0/0x390
[    0.465178]  [<c101cdff>] ? wake_up_process+0xf/0x20
[    0.465178]  [<c1007470>] ? tsc_refine_calibration_work+0x0/0x2a0
[    0.465178]  [<c103536e>] worker_thread+0x10e/0x2a0
[    0.465178]  [<c1035260>] ? worker_thread+0x0/0x2a0
[    0.465178]  [<c1038884>] kthread+0x74/0x80
[    0.465178]  [<c1038810>] ? kthread+0x0/0x80
[    0.465178]  [<c1003096>] kernel_thread_helper+0x6/0x10
[    0.465178] Code: e5 2f c1 31 d2 e8 37 58 fe ff 0f ba 25 04 bf 2f c1 00 19 c0 8b 45 c8 c9 c3 90 8d b4 26 00 00 00 00 55 8b 80 38 01 00 00 89 e5 5d <8b> 40 fc c3 66 90 55 ba c8 59 3a c1 89 e5 57 56 53 8b 3d d0 28 
[    0.465178] EIP: [<c10389aa>] kthread_data+0xa/0x10 SS:ESP 0068:c78e3c80
[    0.465178] CR2: 00000000fffffffc
[    0.465178] ---[ end trace 6d450e935ee1897d ]---
[    0.465178] Fixing recursive fault but reboot is needed!


-- 
 Kirill A. Shutemov

[-- Attachment #2: .config --]
[-- Type: text/plain, Size: 35596 bytes --]

#
# Automatically generated make config: don't edit
# Linux/i386 2.6.37 Kernel Configuration
# Tue Jan 11 09:07:50 2011
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
# CONFIG_X86_64 is not set
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
# CONFIG_NEED_DMA_MAP_STATE is not set
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
# CONFIG_GENERIC_TIME_VSYSCALL is not set
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_DEFAULT_IDLE=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
# CONFIG_HAVE_CPUMASK_OF_CPU_MAP is not set
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
# CONFIG_ZONE_DMA32 is not set
CONFIG_ARCH_POPULATES_NODE_MAP=y
# CONFIG_AUDIT_ARCH is not set
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx"
CONFIG_KTIME_SCALAR=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_HAVE_IRQ_WORK=y
CONFIG_IRQ_WORK=y

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_SWAP=y
# CONFIG_SYSVIPC is not set
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y
# CONFIG_GENERIC_HARDIRQS_NO_DEPRECATED is not set
CONFIG_HAVE_SPARSE_IRQ=y
CONFIG_GENERIC_IRQ_PROBE=y
# CONFIG_GENERIC_PENDING_IRQ is not set
# CONFIG_AUTO_IRQ_AFFINITY is not set
# CONFIG_IRQ_PER_CPU is not set
# CONFIG_HARDIRQS_SW_RESEND is not set
# CONFIG_SPARSE_IRQ is not set

#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
# CONFIG_PREEMPT_RCU is not set
# CONFIG_RCU_TRACE is not set
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_SRCU_SYNCHRONIZE_DELAY=10
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_CGROUPS=y
CONFIG_CGROUP_DEBUG=y
# CONFIG_CGROUP_NS is not set
# CONFIG_CGROUP_FREEZER is not set
# CONFIG_CGROUP_DEVICE is not set
# CONFIG_CPUSETS is not set
# CONFIG_CGROUP_CPUACCT is not set
CONFIG_RESOURCE_COUNTERS=y
CONFIG_CGROUP_MEM_RES_CTLR=y
# CONFIG_CGROUP_MEM_RES_CTLR_SWAP is not set
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_RT_GROUP_SCHED=y
# CONFIG_BLK_CGROUP is not set
CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
CONFIG_USER_NS=y
# CONFIG_PID_NS is not set
CONFIG_NET_NS=y
# CONFIG_SCHED_AUTOGROUP is not set
CONFIG_MM_OWNER=y
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_LZO=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_HAVE_PERF_EVENTS=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
# CONFIG_PERF_COUNTERS is not set
# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_PCI_QUIRKS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_COMPAT_BRK is not set
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_PROFILING is not set
CONFIG_HAVE_OPROFILE=y
# CONFIG_KPROBES is not set
# CONFIG_JUMP_LABEL is not set
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_OPTPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_HW_BREAKPOINT=y
CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y
CONFIG_HAVE_USER_RETURN_NOTIFIER=y
CONFIG_HAVE_PERF_EVENTS_NMI=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y

#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_FORCE_LOAD=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_BLOCK=y
CONFIG_LBDAF=y
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_BLK_DEV_INTEGRITY is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
CONFIG_DEFAULT_NOOP=y
CONFIG_DEFAULT_IOSCHED="noop"
# CONFIG_INLINE_SPIN_TRYLOCK is not set
# CONFIG_INLINE_SPIN_TRYLOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK is not set
# CONFIG_INLINE_SPIN_LOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK_IRQ is not set
# CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set
# CONFIG_INLINE_SPIN_UNLOCK is not set
# CONFIG_INLINE_SPIN_UNLOCK_BH is not set
# CONFIG_INLINE_SPIN_UNLOCK_IRQ is not set
# CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_READ_TRYLOCK is not set
# CONFIG_INLINE_READ_LOCK is not set
# CONFIG_INLINE_READ_LOCK_BH is not set
# CONFIG_INLINE_READ_LOCK_IRQ is not set
# CONFIG_INLINE_READ_LOCK_IRQSAVE is not set
# CONFIG_INLINE_READ_UNLOCK is not set
# CONFIG_INLINE_READ_UNLOCK_BH is not set
# CONFIG_INLINE_READ_UNLOCK_IRQ is not set
# CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_WRITE_TRYLOCK is not set
# CONFIG_INLINE_WRITE_LOCK is not set
# CONFIG_INLINE_WRITE_LOCK_BH is not set
# CONFIG_INLINE_WRITE_LOCK_IRQ is not set
# CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set
# CONFIG_INLINE_WRITE_UNLOCK is not set
# CONFIG_INLINE_WRITE_UNLOCK_BH is not set
# CONFIG_INLINE_WRITE_UNLOCK_IRQ is not set
# CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set
# CONFIG_MUTEX_SPIN_ON_OWNER is not set
# CONFIG_FREEZER is not set

#
# Processor type and features
#
# CONFIG_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
# CONFIG_SMP is not set
# CONFIG_X86_EXTENDED_PLATFORM is not set
# CONFIG_X86_32_IRIS is not set
# CONFIG_SCHED_OMIT_FRAME_POINTER is not set
# CONFIG_PARAVIRT_GUEST is not set
CONFIG_NO_BOOTMEM=y
# CONFIG_MEMTEST is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
CONFIG_M686=y
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_MVIAC7 is not set
# CONFIG_MCORE2 is not set
# CONFIG_MATOM is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CPU=y
CONFIG_X86_INTERNODE_CACHE_SHIFT=5
CONFIG_X86_CMPXCHG=y
CONFIG_CMPXCHG_LOCAL=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_XADD=y
# CONFIG_X86_PPRO_FENCE is not set
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=5
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_CPU_SUP_INTEL=y
CONFIG_CPU_SUP_CYRIX_32=y
CONFIG_CPU_SUP_AMD=y
CONFIG_CPU_SUP_CENTAUR=y
CONFIG_CPU_SUP_TRANSMETA_32=y
CONFIG_CPU_SUP_UMC_32=y
# CONFIG_HPET_TIMER is not set
CONFIG_DMI=y
# CONFIG_IOMMU_HELPER is not set
# CONFIG_IOMMU_API is not set
CONFIG_NR_CPUS=1
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
# CONFIG_X86_UP_APIC is not set
# CONFIG_X86_MCE is not set
CONFIG_VM86=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_X86_REBOOTFIXUPS is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
# CONFIG_NOHIGHMEM is not set
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_HIGHMEM=y
# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
# CONFIG_ARCH_DMA_ADDR_T_64BIT is not set
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ILLEGAL_POINTER_VALUE=0
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_SPARSEMEM_STATIC=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=999999
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_NEED_PER_CPU_KM=y
# CONFIG_HIGHPTE is not set
# CONFIG_X86_CHECK_BIOS_CORRUPTION is not set
CONFIG_X86_RESERVE_LOW=64
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_MTRR_SANITIZER is not set
CONFIG_X86_PAT=y
CONFIG_ARCH_USES_PG_UNCACHED=y
# CONFIG_EFI is not set
# CONFIG_SECCOMP is not set
# CONFIG_CC_STACKPROTECTOR is not set
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
# CONFIG_SCHED_HRTICK is not set
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not set
CONFIG_PHYSICAL_START=0x1000000
# CONFIG_RELOCATABLE is not set
CONFIG_PHYSICAL_ALIGN=0x1000000
# CONFIG_COMPAT_VDSO is not set
# CONFIG_CMDLINE_BOOL is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y

#
# Power management and ACPI options
#
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
# CONFIG_SUSPEND is not set
# CONFIG_HIBERNATION is not set
# CONFIG_PM_RUNTIME is not set
CONFIG_ACPI=y
# CONFIG_ACPI_PROCFS is not set
# CONFIG_ACPI_PROCFS_POWER is not set
# CONFIG_ACPI_EC_DEBUGFS is not set
# CONFIG_ACPI_PROC_EVENT is not set
# CONFIG_ACPI_AC is not set
# CONFIG_ACPI_BATTERY is not set
# CONFIG_ACPI_BUTTON is not set
# CONFIG_ACPI_FAN is not set
# CONFIG_ACPI_DOCK is not set
# CONFIG_ACPI_PROCESSOR is not set
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
# CONFIG_ACPI_PCI_SLOT is not set
CONFIG_X86_PM_TIMER=y
# CONFIG_ACPI_CONTAINER is not set
# CONFIG_ACPI_SBS is not set
# CONFIG_ACPI_HED is not set
# CONFIG_ACPI_APEI is not set
# CONFIG_SFI is not set

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
# CONFIG_CPU_IDLE is not set

#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_DOMAINS=y
# CONFIG_PCI_CNB20LE_QUIRK is not set
# CONFIG_PCIEPORTBUS is not set
# CONFIG_ARCH_SUPPORTS_MSI is not set
# CONFIG_PCI_DEBUG is not set
# CONFIG_PCI_STUB is not set
# CONFIG_PCI_IOV is not set
CONFIG_PCI_IOAPIC=y
CONFIG_ISA_DMA_API=y
# CONFIG_ISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set
# CONFIG_OLPC is not set
# CONFIG_OLPC_OPENFIRMWARE is not set
CONFIG_AMD_NB=y
# CONFIG_PCCARD is not set
# CONFIG_HOTPLUG_PCI is not set

#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
CONFIG_HAVE_AOUT=y
# CONFIG_BINFMT_AOUT is not set
# CONFIG_BINFMT_MISC is not set
CONFIG_HAVE_ATOMIC_IOMAP=y
CONFIG_HAVE_TEXT_POKE_SMP=y
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=y
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
# CONFIG_XFRM_STATISTICS is not set
CONFIG_XFRM_IPCOMP=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_ASK_IP_FIB_HASH=y
# CONFIG_IP_FIB_TRIE is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_VERBOSE=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y
CONFIG_NET_IPIP=y
CONFIG_NET_IPGRE_DEMUX=y
CONFIG_NET_IPGRE=y
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_MROUTE_MULTIPLE_TABLES=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
CONFIG_ARPD=y
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=y
CONFIG_INET_ESP=y
CONFIG_INET_IPCOMP=y
CONFIG_INET_XFRM_TUNNEL=y
CONFIG_INET_TUNNEL=y
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
CONFIG_INET_LRO=y
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
CONFIG_IPV6=y
CONFIG_IPV6_PRIVACY=y
CONFIG_IPV6_ROUTER_PREF=y
# CONFIG_IPV6_ROUTE_INFO is not set
# CONFIG_IPV6_OPTIMISTIC_DAD is not set
CONFIG_INET6_AH=y
CONFIG_INET6_ESP=y
CONFIG_INET6_IPCOMP=y
# CONFIG_IPV6_MIP6 is not set
CONFIG_INET6_XFRM_TUNNEL=y
CONFIG_INET6_TUNNEL=y
CONFIG_INET6_XFRM_MODE_TRANSPORT=y
CONFIG_INET6_XFRM_MODE_TUNNEL=y
CONFIG_INET6_XFRM_MODE_BEET=y
# CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set
CONFIG_IPV6_SIT=y
# CONFIG_IPV6_SIT_6RD is not set
CONFIG_IPV6_NDISC_NODETYPE=y
# CONFIG_IPV6_TUNNEL is not set
# CONFIG_IPV6_MULTIPLE_TABLES is not set
# CONFIG_IPV6_MROUTE is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
# CONFIG_NETFILTER is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_RDS is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_L2TP is not set
CONFIG_STP=y
CONFIG_GARP=y
CONFIG_BRIDGE=y
CONFIG_BRIDGE_IGMP_SNOOPING=y
# CONFIG_NET_DSA is not set
CONFIG_VLAN_8021Q=y
CONFIG_VLAN_8021Q_GVRP=y
# CONFIG_DECNET is not set
CONFIG_LLC=y
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_PHONET is not set
# CONFIG_IEEE802154 is not set
# CONFIG_NET_SCHED is not set
# CONFIG_DCB is not set
CONFIG_DNS_RESOLVER=y
# CONFIG_BATMAN_ADV is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
CONFIG_FIB_RULES=y
CONFIG_WIRELESS=y
# CONFIG_CFG80211 is not set
# CONFIG_LIB80211 is not set

#
# CFG80211 needs to be enabled for MAC80211
#

#
# Some wireless drivers require a rate control algorithm
#
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
CONFIG_NET_9P=y
CONFIG_NET_9P_VIRTIO=y
CONFIG_NET_9P_DEBUG=y
# CONFIG_CAIF is not set
# CONFIG_CEPH_LIB is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH=""
# CONFIG_DEVTMPFS is not set
CONFIG_STANDALONE=y
# CONFIG_PREVENT_FIRMWARE_BUILD is not set
CONFIG_FW_LOADER=y
# CONFIG_FIRMWARE_IN_KERNEL is not set
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y
# CONFIG_MTD is not set
# CONFIG_PARPORT is not set
CONFIG_PNP=y
# CONFIG_PNP_DEBUG_MESSAGES is not set

#
# Protocols
#
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
# CONFIG_BLK_DEV_LOOP is not set
# CONFIG_BLK_DEV_DRBD is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_RAM is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_VIRTIO_BLK is not set
# CONFIG_BLK_DEV_HD is not set
# CONFIG_BLK_DEV_RBD is not set
# CONFIG_MISC_DEVICES is not set
CONFIG_HAVE_IDE=y
# CONFIG_IDE is not set

#
# SCSI device support
#
CONFIG_SCSI_MOD=y
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
# CONFIG_SCSI_NETLINK is not set
# CONFIG_SCSI_PROC_FS is not set

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set
# CONFIG_CHR_DEV_SCH is not set
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set
# CONFIG_SCSI_SCAN_ASYNC is not set
CONFIG_SCSI_WAIT_SCAN=m

#
# SCSI Transports
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
# CONFIG_SCSI_LOWLEVEL is not set
# CONFIG_SCSI_DH is not set
# CONFIG_SCSI_OSD_INITIATOR is not set
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
# CONFIG_ATA_VERBOSE_ERROR is not set
# CONFIG_ATA_ACPI is not set
CONFIG_SATA_PMP=y

#
# Controllers with non-SFF native interface
#
# CONFIG_SATA_AHCI is not set
# CONFIG_SATA_AHCI_PLATFORM is not set
# CONFIG_SATA_INIC162X is not set
# CONFIG_SATA_ACARD_AHCI is not set
# CONFIG_SATA_SIL24 is not set
CONFIG_ATA_SFF=y

#
# SFF controllers with custom DMA interface
#
# CONFIG_PDC_ADMA is not set
# CONFIG_SATA_QSTOR is not set
# CONFIG_SATA_SX4 is not set
CONFIG_ATA_BMDMA=y

#
# SATA SFF controllers with BMDMA
#
CONFIG_ATA_PIIX=y
# CONFIG_SATA_MV is not set
# CONFIG_SATA_NV is not set
# CONFIG_SATA_PROMISE is not set
# CONFIG_SATA_SIL is not set
# CONFIG_SATA_SIS is not set
# CONFIG_SATA_SVW is not set
# CONFIG_SATA_ULI is not set
# CONFIG_SATA_VIA is not set
# CONFIG_SATA_VITESSE is not set

#
# PATA SFF controllers with BMDMA
#
# CONFIG_PATA_ALI is not set
# CONFIG_PATA_AMD is not set
# CONFIG_PATA_ARTOP is not set
# CONFIG_PATA_ATIIXP is not set
# CONFIG_PATA_ATP867X is not set
# CONFIG_PATA_CMD64X is not set
# CONFIG_PATA_CS5520 is not set
# CONFIG_PATA_CS5530 is not set
# CONFIG_PATA_CS5535 is not set
# CONFIG_PATA_CS5536 is not set
# CONFIG_PATA_CYPRESS is not set
# CONFIG_PATA_EFAR is not set
# CONFIG_PATA_HPT366 is not set
# CONFIG_PATA_HPT37X is not set
# CONFIG_PATA_HPT3X2N is not set
# CONFIG_PATA_HPT3X3 is not set
# CONFIG_PATA_IT8213 is not set
# CONFIG_PATA_IT821X is not set
# CONFIG_PATA_JMICRON is not set
# CONFIG_PATA_MARVELL is not set
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NINJA32 is not set
# CONFIG_PATA_NS87415 is not set
# CONFIG_PATA_OLDPIIX is not set
# CONFIG_PATA_OPTIDMA is not set
# CONFIG_PATA_PDC2027X is not set
# CONFIG_PATA_PDC_OLD is not set
# CONFIG_PATA_RADISYS is not set
# CONFIG_PATA_RDC is not set
# CONFIG_PATA_SC1200 is not set
# CONFIG_PATA_SCH is not set
# CONFIG_PATA_SERVERWORKS is not set
# CONFIG_PATA_SIL680 is not set
# CONFIG_PATA_SIS is not set
# CONFIG_PATA_TOSHIBA is not set
# CONFIG_PATA_TRIFLEX is not set
# CONFIG_PATA_VIA is not set
# CONFIG_PATA_WINBOND is not set

#
# PIO-only SFF controllers
#
# CONFIG_PATA_CMD640_PCI is not set
# CONFIG_PATA_MPIIX is not set
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_RZ1000 is not set

#
# Generic fallback / legacy drivers
#
# CONFIG_ATA_GENERIC is not set
# CONFIG_PATA_LEGACY is not set
# CONFIG_MD is not set
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#
# CONFIG_FIREWIRE is not set
# CONFIG_FIREWIRE_NOSY is not set
# CONFIG_I2O is not set
# CONFIG_MACINTOSH_DRIVERS is not set
CONFIG_NETDEVICES=y
CONFIG_DUMMY=y
CONFIG_BONDING=y
# CONFIG_MACVLAN is not set
# CONFIG_EQUALIZER is not set
CONFIG_TUN=y
CONFIG_VETH=y
# CONFIG_NET_SB1000 is not set
# CONFIG_ARCNET is not set
# CONFIG_MII is not set
# CONFIG_PHYLIB is not set
# CONFIG_NET_ETHERNET is not set
CONFIG_NETDEV_1000=y
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
CONFIG_E1000=y
# CONFIG_E1000E is not set
# CONFIG_IP1000 is not set
# CONFIG_IGB is not set
# CONFIG_IGBVF is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set
# CONFIG_BNX2 is not set
# CONFIG_CNIC is not set
# CONFIG_QLA3XXX is not set
# CONFIG_ATL1 is not set
# CONFIG_ATL1E is not set
# CONFIG_ATL1C is not set
# CONFIG_JME is not set
# CONFIG_STMMAC_ETH is not set
# CONFIG_PCH_GBE is not set
# CONFIG_NETDEV_10000 is not set
# CONFIG_TR is not set
# CONFIG_WLAN is not set

#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
# CONFIG_WAN is not set

#
# CAIF transport drivers
#
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_VIRTIO_NET is not set
# CONFIG_VMXNET3 is not set
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
# CONFIG_INPUT_POLLDEV is not set
# CONFIG_INPUT_SPARSEKMAP is not set

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_OPENCORES is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_SERIO_ALTERA_PS2 is not set
# CONFIG_SERIO_PS2MULT is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
# CONFIG_DEVKMEM is not set
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_N_GSM is not set
# CONFIG_NOZOMI is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_PNP=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
# CONFIG_SERIAL_8250_MANY_PORTS is not set
# CONFIG_SERIAL_8250_SHARE_IRQ is not set
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
# CONFIG_SERIAL_8250_RSA is not set

#
# Non-8250 serial port support
#
# CONFIG_SERIAL_MFD_HSU is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_JSM is not set
# CONFIG_SERIAL_TIMBERDALE is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
# CONFIG_LEGACY_PTYS is not set
# CONFIG_VIRTIO_CONSOLE is not set
# CONFIG_IPMI_HANDLER is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
# CONFIG_RTC is not set
# CONFIG_GEN_RTC is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set
# CONFIG_MWAVE is not set
# CONFIG_PC8736x_GPIO is not set
# CONFIG_NSC_GPIO is not set
# CONFIG_CS5535_GPIO is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HPET is not set
# CONFIG_HANGCHECK_TIMER is not set
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set
CONFIG_DEVPORT=y
# CONFIG_RAMOOPS is not set
# CONFIG_I2C is not set
# CONFIG_SPI is not set

#
# PPS support
#
# CONFIG_PPS is not set
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
# CONFIG_GPIOLIB is not set
# CONFIG_W1 is not set
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
# CONFIG_TEST_POWER is not set
# CONFIG_HWMON is not set
# CONFIG_THERMAL is not set
# CONFIG_WATCHDOG is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
CONFIG_MFD_SUPPORT=y
# CONFIG_MFD_CORE is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_ABX500_CORE is not set
# CONFIG_LPC_SCH is not set
# CONFIG_MFD_RDC321X is not set
# CONFIG_MFD_JANZ_CMODIO is not set
# CONFIG_MFD_VX855 is not set
# CONFIG_REGULATOR is not set
# CONFIG_MEDIA_SUPPORT is not set

#
# Graphics support
#
# CONFIG_AGP is not set
CONFIG_VGA_ARB=y
CONFIG_VGA_ARB_MAX_GPUS=16
# CONFIG_VGA_SWITCHEROO is not set
# CONFIG_DRM is not set
# CONFIG_STUB_POULSBO is not set
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
# CONFIG_FB is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

#
# Display device support
#
# CONFIG_DISPLAY_SUPPORT is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_VGACON_SOFT_SCROLLBACK is not set
CONFIG_DUMMY_CONSOLE=y
# CONFIG_SOUND is not set
# CONFIG_HID_SUPPORT is not set
# CONFIG_USB_SUPPORT is not set
# CONFIG_UWB is not set
# CONFIG_MMC is not set
# CONFIG_MEMSTICK is not set
# CONFIG_NEW_LEDS is not set
# CONFIG_ACCESSIBILITY is not set
# CONFIG_INFINIBAND is not set
# CONFIG_EDAC is not set
# CONFIG_RTC_CLASS is not set
# CONFIG_DMADEVICES is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set
# CONFIG_STAGING is not set
# CONFIG_X86_PLATFORM_DEVICES is not set

#
# Firmware Drivers
#
# CONFIG_EDD is not set
CONFIG_FIRMWARE_MEMMAP=y
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set
# CONFIG_DMIID is not set
# CONFIG_ISCSI_IBFT_FIND is not set

#
# File systems
#
# CONFIG_EXT2_FS is not set
# CONFIG_EXT3_FS is not set
CONFIG_EXT4_FS=y
CONFIG_EXT4_USE_FOR_EXT23=y
CONFIG_EXT4_FS_XATTR=y
# CONFIG_EXT4_FS_POSIX_ACL is not set
# CONFIG_EXT4_FS_SECURITY is not set
# CONFIG_EXT4_DEBUG is not set
CONFIG_JBD2=y
# CONFIG_JBD2_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
CONFIG_EXPORTFS=m
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_FANOTIFY is not set
# CONFIG_QUOTA is not set
# CONFIG_QUOTACTL is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set
CONFIG_GENERIC_ACL=y

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
# CONFIG_PROC_KCORE is not set
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
# CONFIG_CONFIGFS_FS is not set
# CONFIG_MISC_FILESYSTEMS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
CONFIG_NFS_V4_1=y
CONFIG_PNFS_FILE_LAYOUT=m
# CONFIG_NFS_USE_LEGACY_DNS is not set
CONFIG_NFS_USE_KERNEL_DNS=y
CONFIG_NFS_USE_NEW_IDMAPPER=y
CONFIG_NFSD=m
CONFIG_NFSD_DEPRECATED=y
CONFIG_NFSD_V2_ACL=y
CONFIG_NFSD_V3=y
CONFIG_NFSD_V3_ACL=y
CONFIG_NFSD_V4=y
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_NFS_ACL_SUPPORT=m
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=m
CONFIG_SUNRPC_GSS=m
CONFIG_RPCSEC_GSS_KRB5=m
# CONFIG_CEPH_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
CONFIG_9P_FS=y
CONFIG_9P_FS_POSIX_ACL=y

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_NLS is not set
# CONFIG_DLM is not set

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_PRINTK_TIME=y
# CONFIG_ENABLE_WARN_DEPRECATED is not set
# CONFIG_ENABLE_MUST_CHECK is not set
CONFIG_FRAME_WARN=1024
# CONFIG_MAGIC_SYSRQ is not set
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
CONFIG_LOCKUP_DETECTOR=y
CONFIG_HARDLOCKUP_DETECTOR=y
# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0
# CONFIG_DETECT_HUNG_TASK is not set
# CONFIG_SCHED_DEBUG is not set
# CONFIG_SCHEDSTATS is not set
# CONFIG_TIMER_STATS is not set
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_SLUB_DEBUG_ON is not set
# CONFIG_SLUB_STATS is not set
CONFIG_DEBUG_KMEMLEAK=y
CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE=400
CONFIG_DEBUG_KMEMLEAK_TEST=y
# CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_BKL=y
CONFIG_DEBUG_LOCK_ALLOC=y
# CONFIG_PROVE_LOCKING is not set
# CONFIG_SPARSE_RCU_POINTER is not set
CONFIG_LOCKDEP=y
# CONFIG_LOCK_STAT is not set
CONFIG_DEBUG_LOCKDEP=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_HIGHMEM is not set
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_INFO_REDUCED is not set
CONFIG_DEBUG_VM=y
# CONFIG_DEBUG_VIRTUAL is not set
# CONFIG_DEBUG_WRITECOUNT is not set
CONFIG_DEBUG_MEMORY_INIT=y
# CONFIG_DEBUG_LIST is not set
# CONFIG_TEST_LIST_SORT is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
# CONFIG_DEBUG_CREDENTIALS is not set
CONFIG_ARCH_WANT_FRAME_POINTERS=y
CONFIG_FRAME_POINTER=y
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
# CONFIG_LKDTM is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_LATENCYTOP is not set
# CONFIG_SYSCTL_SYSCALL_CHECK is not set
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_USER_STACKTRACE_SUPPORT=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST=y
CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACING_SUPPORT=y
# CONFIG_FTRACE is not set
# CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set
CONFIG_DYNAMIC_DEBUG=y
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_ATOMIC64_SELFTEST is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
CONFIG_HAVE_ARCH_KMEMCHECK=y
# CONFIG_KMEMCHECK is not set
# CONFIG_STRICT_DEVMEM is not set
# CONFIG_X86_VERBOSE_BOOTUP is not set
CONFIG_EARLY_PRINTK=y
# CONFIG_EARLY_PRINTK_DBGP is not set
CONFIG_DEBUG_STACKOVERFLOW=y
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_X86_PTDUMP is not set
CONFIG_DEBUG_RODATA=y
CONFIG_DEBUG_RODATA_TEST=y
# CONFIG_DEBUG_SET_MODULE_RONX is not set
# CONFIG_DEBUG_NX_TEST is not set
CONFIG_DOUBLEFAULT=y
# CONFIG_IOMMU_STRESS is not set
CONFIG_HAVE_MMIOTRACE_SUPPORT=y
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
CONFIG_IO_DELAY_0X80=y
# CONFIG_IO_DELAY_0XED is not set
# CONFIG_IO_DELAY_UDELAY is not set
# CONFIG_IO_DELAY_NONE is not set
CONFIG_DEFAULT_IO_DELAY_TYPE=0
CONFIG_DEBUG_BOOT_PARAMS=y
# CONFIG_CPA_DEBUG is not set
# CONFIG_OPTIMIZE_INLINING is not set
# CONFIG_DEBUG_STRICT_USER_COPY_CHECKS is not set

#
# Security options
#
CONFIG_KEYS=y
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set
# CONFIG_SECURITY_DMESG_RESTRICT is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITYFS is not set
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP2=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
# CONFIG_CRYPTO_GF128MUL is not set
# CONFIG_CRYPTO_NULL is not set
CONFIG_CRYPTO_WORKQUEUE=y
# CONFIG_CRYPTO_CRYPTD is not set
CONFIG_CRYPTO_AUTHENC=y
# CONFIG_CRYPTO_TEST is not set

#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_SEQIV is not set

#
# Block modes
#
CONFIG_CRYPTO_CBC=y
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
# CONFIG_CRYPTO_ECB is not set
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set

#
# Hash modes
#
CONFIG_CRYPTO_HMAC=y
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_VMAC is not set

#
# Digest
#
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_CRC32C_INTEL is not set
# CONFIG_CRYPTO_GHASH is not set
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
CONFIG_CRYPTO_SHA1=y
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set

#
# Ciphers
#
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_AES_586 is not set
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SALSA20_586 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_TWOFISH_586 is not set

#
# Compression
#
CONFIG_CRYPTO_DEFLATE=y
# CONFIG_CRYPTO_ZLIB is not set
# CONFIG_CRYPTO_LZO is not set

#
# Random Number Generation
#
CONFIG_CRYPTO_ANSI_CPRNG=y
CONFIG_CRYPTO_HW=y
# CONFIG_CRYPTO_DEV_PADLOCK is not set
# CONFIG_CRYPTO_DEV_GEODE is not set
# CONFIG_CRYPTO_DEV_HIFN_795X is not set
CONFIG_HAVE_KVM=y
CONFIG_VIRTUALIZATION=y
# CONFIG_KVM is not set
# CONFIG_VHOST_NET is not set
# CONFIG_LGUEST is not set
CONFIG_VIRTIO=y
CONFIG_VIRTIO_RING=y
CONFIG_VIRTIO_PCI=y
# CONFIG_VIRTIO_BALLOON is not set
# CONFIG_BINARY_PRINTF is not set

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_FIND_FIRST_BIT=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_GENERIC_FIND_LAST_BIT=y
# CONFIG_CRC_CCITT is not set
CONFIG_CRC16=y
# CONFIG_CRC_T10DIF is not set
# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_LZO_DECOMPRESS=y
CONFIG_DECOMPRESS_GZIP=y
CONFIG_DECOMPRESS_BZIP2=y
CONFIG_DECOMPRESS_LZMA=y
CONFIG_DECOMPRESS_LZO=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_NLATTR=y

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [tip:x86/tsc] x86: Improve TSC calibration using a delayed workqueue
  2011-01-11  8:13   ` Kirill A. Shutemov
@ 2011-01-11  8:26     ` Thomas Gleixner
  2011-01-11  8:30       ` Kirill A. Shutemov
  0 siblings, 1 reply; 24+ messages in thread
From: Thomas Gleixner @ 2011-01-11  8:26 UTC (permalink / raw)
  To: Kirill A. Shutemov
  Cc: mingo, hpa, linux-kernel, andi, johnstul, williams, schwidefsky,
	mingo, linux-tip-commits

On Tue, 11 Jan 2011, Kirill A. Shutemov wrote:

> On Sun, Dec 05, 2010 at 11:18:53AM +0000, tip-bot for John Stultz wrote:
> > Commit-ID:  08ec0c58fb8a05d3191d5cb6f5d6f81adb419798
> > Gitweb:     http://git.kernel.org/tip/08ec0c58fb8a05d3191d5cb6f5d6f81adb419798
> > Author:     John Stultz <johnstul@us.ibm.com>
> > AuthorDate: Tue, 27 Jul 2010 17:00:00 -0700
> > Committer:  John Stultz <john.stultz@linaro.org>
> > CommitDate: Thu, 2 Dec 2010 16:48:37 -0800
> > 
> > x86: Improve TSC calibration using a delayed workqueue
> 
> This commit breaks booting the kernel in qemu with enabled KVM on my machine.
> .config attached.
> 
> [    0.424013] divide error: 0000 [#1] 

Got fixed by a8760ec (x86: Check tsc available/disabled in the delayed
init function)

Thanks,

	tglx

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [tip:x86/tsc] x86: Improve TSC calibration using a delayed workqueue
  2011-01-11  8:26     ` Thomas Gleixner
@ 2011-01-11  8:30       ` Kirill A. Shutemov
  2011-01-11  8:37         ` Thomas Gleixner
  0 siblings, 1 reply; 24+ messages in thread
From: Kirill A. Shutemov @ 2011-01-11  8:30 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: mingo, hpa, linux-kernel, andi, johnstul, williams, schwidefsky,
	mingo, linux-tip-commits

On Tue, Jan 11, 2011 at 09:26:48AM +0100, Thomas Gleixner wrote:
> On Tue, 11 Jan 2011, Kirill A. Shutemov wrote:
> 
> > On Sun, Dec 05, 2010 at 11:18:53AM +0000, tip-bot for John Stultz wrote:
> > > Commit-ID:  08ec0c58fb8a05d3191d5cb6f5d6f81adb419798
> > > Gitweb:     http://git.kernel.org/tip/08ec0c58fb8a05d3191d5cb6f5d6f81adb419798
> > > Author:     John Stultz <johnstul@us.ibm.com>
> > > AuthorDate: Tue, 27 Jul 2010 17:00:00 -0700
> > > Committer:  John Stultz <john.stultz@linaro.org>
> > > CommitDate: Thu, 2 Dec 2010 16:48:37 -0800
> > > 
> > > x86: Improve TSC calibration using a delayed workqueue
> > 
> > This commit breaks booting the kernel in qemu with enabled KVM on my machine.
> > .config attached.
> > 
> > [    0.424013] divide error: 0000 [#1] 
> 
> Got fixed by a8760ec (x86: Check tsc available/disabled in the delayed
> init function)

No, it didn't. :(

I am able to reproduce it on current Linus' tree (v2.6.37-4700-g8adbf8d).

-- 
 Kirill A. Shutemov

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [tip:x86/tsc] x86: Improve TSC calibration using a delayed workqueue
  2011-01-11  8:30       ` Kirill A. Shutemov
@ 2011-01-11  8:37         ` Thomas Gleixner
  2011-01-11  9:56           ` Kirill A. Shutemov
  0 siblings, 1 reply; 24+ messages in thread
From: Thomas Gleixner @ 2011-01-11  8:37 UTC (permalink / raw)
  To: Kirill A. Shutemov
  Cc: mingo, hpa, linux-kernel, andi, johnstul, williams, schwidefsky,
	mingo, linux-tip-commits

On Tue, 11 Jan 2011, Kirill A. Shutemov wrote:

> On Tue, Jan 11, 2011 at 09:26:48AM +0100, Thomas Gleixner wrote:
> > On Tue, 11 Jan 2011, Kirill A. Shutemov wrote:
> > 
> > > On Sun, Dec 05, 2010 at 11:18:53AM +0000, tip-bot for John Stultz wrote:
> > > > Commit-ID:  08ec0c58fb8a05d3191d5cb6f5d6f81adb419798
> > > > Gitweb:     http://git.kernel.org/tip/08ec0c58fb8a05d3191d5cb6f5d6f81adb419798
> > > > Author:     John Stultz <johnstul@us.ibm.com>
> > > > AuthorDate: Tue, 27 Jul 2010 17:00:00 -0700
> > > > Committer:  John Stultz <john.stultz@linaro.org>
> > > > CommitDate: Thu, 2 Dec 2010 16:48:37 -0800
> > > > 
> > > > x86: Improve TSC calibration using a delayed workqueue
> > > 
> > > This commit breaks booting the kernel in qemu with enabled KVM on my machine.
> > > .config attached.
> > > 
> > > [    0.424013] divide error: 0000 [#1] 
> > 
> > Got fixed by a8760ec (x86: Check tsc available/disabled in the delayed
> > init function)
> 
> No, it didn't. :(
> 
> I am able to reproduce it on current Linus' tree (v2.6.37-4700-g8adbf8d).

Does the patch below fix it ? We can end up with tsc_khz=0 there :(

Thanks,

	tglx
---
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 03d2ea8..6a7d726 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -959,7 +959,8 @@ static void tsc_refine_calibration_work(struct work_struct *work)
 					(unsigned long)tsc_khz % 1000);
 
 out:
-	clocksource_register_khz(&clocksource_tsc, tsc_khz);
+	if (tsc_khz)
+		clocksource_register_khz(&clocksource_tsc, tsc_khz);
 }
 
 

^ permalink raw reply related	[flat|nested] 24+ messages in thread

* Re: [tip:x86/tsc] x86: Improve TSC calibration using a delayed workqueue
  2011-01-11  8:37         ` Thomas Gleixner
@ 2011-01-11  9:56           ` Kirill A. Shutemov
  2011-01-11 10:26             ` Thomas Gleixner
  2011-01-13 17:49             ` Konrad Rzeszutek Wilk
  0 siblings, 2 replies; 24+ messages in thread
From: Kirill A. Shutemov @ 2011-01-11  9:56 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: mingo, hpa, linux-kernel, andi, johnstul, williams, schwidefsky,
	mingo, linux-tip-commits

On Tue, Jan 11, 2011 at 09:37:15AM +0100, Thomas Gleixner wrote:
> On Tue, 11 Jan 2011, Kirill A. Shutemov wrote:
> 
> > On Tue, Jan 11, 2011 at 09:26:48AM +0100, Thomas Gleixner wrote:
> > > On Tue, 11 Jan 2011, Kirill A. Shutemov wrote:
> > > 
> > > > On Sun, Dec 05, 2010 at 11:18:53AM +0000, tip-bot for John Stultz wrote:
> > > > > Commit-ID:  08ec0c58fb8a05d3191d5cb6f5d6f81adb419798
> > > > > Gitweb:     http://git.kernel.org/tip/08ec0c58fb8a05d3191d5cb6f5d6f81adb419798
> > > > > Author:     John Stultz <johnstul@us.ibm.com>
> > > > > AuthorDate: Tue, 27 Jul 2010 17:00:00 -0700
> > > > > Committer:  John Stultz <john.stultz@linaro.org>
> > > > > CommitDate: Thu, 2 Dec 2010 16:48:37 -0800
> > > > > 
> > > > > x86: Improve TSC calibration using a delayed workqueue
> > > > 
> > > > This commit breaks booting the kernel in qemu with enabled KVM on my machine.
> > > > .config attached.
> > > > 
> > > > [    0.424013] divide error: 0000 [#1] 
> > > 
> > > Got fixed by a8760ec (x86: Check tsc available/disabled in the delayed
> > > init function)
> > 
> > No, it didn't. :(
> > 
> > I am able to reproduce it on current Linus' tree (v2.6.37-4700-g8adbf8d).
> 
> Does the patch below fix it ? We can end up with tsc_khz=0 there :(

Yes, it does.

Bisected-and-tested-by: Kirill A. Shutemov <kas@openvz.org>

Thanks.

> 
> Thanks,
> 
> 	tglx
> ---
> diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
> index 03d2ea8..6a7d726 100644
> --- a/arch/x86/kernel/tsc.c
> +++ b/arch/x86/kernel/tsc.c
> @@ -959,7 +959,8 @@ static void tsc_refine_calibration_work(struct work_struct *work)
>  					(unsigned long)tsc_khz % 1000);
>  
>  out:
> -	clocksource_register_khz(&clocksource_tsc, tsc_khz);
> +	if (tsc_khz)
> +		clocksource_register_khz(&clocksource_tsc, tsc_khz);
>  }
>  
>  

-- 
 Kirill A. Shutemov

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [tip:x86/tsc] x86: Improve TSC calibration using a delayed workqueue
  2011-01-11  9:56           ` Kirill A. Shutemov
@ 2011-01-11 10:26             ` Thomas Gleixner
  2011-01-13 17:49             ` Konrad Rzeszutek Wilk
  1 sibling, 0 replies; 24+ messages in thread
From: Thomas Gleixner @ 2011-01-11 10:26 UTC (permalink / raw)
  To: Kirill A. Shutemov
  Cc: mingo, hpa, linux-kernel, andi, johnstul, williams, schwidefsky,
	mingo, linux-tip-commits

On Tue, 11 Jan 2011, Kirill A. Shutemov wrote:
> On Tue, Jan 11, 2011 at 09:37:15AM +0100, Thomas Gleixner wrote:
> > Does the patch below fix it ? We can end up with tsc_khz=0 there :(
> 
> Yes, it does.
> 
> Bisected-and-tested-by: Kirill A. Shutemov <kas@openvz.org>

Looking deeper, we should avoid to schedule the delayed init
completely. Does that work as well ?

Thanks,

	tglx
---

diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 03d2ea8..823f79a 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -965,7 +965,7 @@ out:
 
 static int __init init_tsc_clocksource(void)
 {
-	if (!cpu_has_tsc || tsc_disabled > 0)
+	if (!cpu_has_tsc || tsc_disabled > 0 || !tsc_khz)
 		return 0;
 
 	if (tsc_clocksource_reliable)

^ permalink raw reply related	[flat|nested] 24+ messages in thread

* Re: [tip:x86/tsc] x86: Improve TSC calibration using a delayed workqueue
  2011-01-11  9:56           ` Kirill A. Shutemov
  2011-01-11 10:26             ` Thomas Gleixner
@ 2011-01-13 17:49             ` Konrad Rzeszutek Wilk
  2011-01-13 18:01               ` john stultz
  1 sibling, 1 reply; 24+ messages in thread
From: Konrad Rzeszutek Wilk @ 2011-01-13 17:49 UTC (permalink / raw)
  To: Kirill A. Shutemov, Jeremy Fitzhardinge, Stefano Stabellini,
	Ian Campbell
  Cc: Thomas Gleixner, mingo, hpa, linux-kernel, andi, johnstul,
	williams, schwidefsky, mingo, linux-tip-commits

On Tue, Jan 11, 2011 at 11:56:40AM +0200, Kirill A. Shutemov wrote:
> On Tue, Jan 11, 2011 at 09:37:15AM +0100, Thomas Gleixner wrote:
> > On Tue, 11 Jan 2011, Kirill A. Shutemov wrote:
> > 
> > > On Tue, Jan 11, 2011 at 09:26:48AM +0100, Thomas Gleixner wrote:
> > > > On Tue, 11 Jan 2011, Kirill A. Shutemov wrote:
> > > > 
> > > > > On Sun, Dec 05, 2010 at 11:18:53AM +0000, tip-bot for John Stultz wrote:
> > > > > > Commit-ID:  08ec0c58fb8a05d3191d5cb6f5d6f81adb419798
> > > > > > Gitweb:     http://git.kernel.org/tip/08ec0c58fb8a05d3191d5cb6f5d6f81adb419798
> > > > > > Author:     John Stultz <johnstul@us.ibm.com>
> > > > > > AuthorDate: Tue, 27 Jul 2010 17:00:00 -0700
> > > > > > Committer:  John Stultz <john.stultz@linaro.org>
> > > > > > CommitDate: Thu, 2 Dec 2010 16:48:37 -0800
> > > > > > 
> > > > > > x86: Improve TSC calibration using a delayed workqueue
> > > > > 
> > > > > This commit breaks booting the kernel in qemu with enabled KVM on my machine.
> > > > > .config attached.
> > > > > 
> > > > > [    0.424013] divide error: 0000 [#1] 
> > > > 
> > > > Got fixed by a8760ec (x86: Check tsc available/disabled in the delayed
> > > > init function)
> > > 
> > > No, it didn't. :(
> > > 
> > > I am able to reproduce it on current Linus' tree (v2.6.37-4700-g8adbf8d).
> > 
> > Does the patch below fix it ? We can end up with tsc_khz=0 there :(
> 
> Yes, it does.

Interestingly enough, when you run Linux under Xen (as Domain 0) you
get the same stack-trace. With both patches (a8760ec, and the patch
posted earlier) I still get the failure.

I've traced it down to the fact that when we boot under Xen we do
not have the HPET enabled nor the ACPI PM timer setup. The 
hpet_enable() is never called (b/c xen_time_init is called), and
for calibration of tsc_khz (calibrate_tsc == xen_tsc_khz) we
get a valid value.

So 'tsc_read_refs' tries to read the ACPI PM timer (acpi_pm_read_early),
however that is disabled under Xen:

[    1.099272] calling  init_acpi_pm_clocksource+0x0/0xdc @ 1
[    1.140186] PM-Timer failed consistency check  (0x0xffffff) - aborting.

So the tsc_calibrate_check gets called, it can't do HPET, and reading
from ACPI PM timer results in getting 0xffffff.. .. and
(0xffff..-0xffff..)/some other value results in div_zero.

There is a check in 'tsc_refine_calibration_work' for invalid
values:

   /* hpet or pmtimer available ? */
         if (!hpet && !ref_start && !ref_stop)
                  goto out;

But since ref_start and ref_stop have 0xffffff it does not trigger.

This little fix does it however. Thought it will of course not
recalibrate the tsc - is that a horrible thing? Should we look
at making tsc_read_refs also use the pv-ops in case both hpet and
acpi pm timer are disabled?


Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff --git a/drivers/clocksource/acpi_pm.c b/drivers/clocksource/acpi_pm.c
index cfb0f52..84ff897 100644
--- a/drivers/clocksource/acpi_pm.c
+++ b/drivers/clocksource/acpi_pm.c
@@ -207,6 +208,7 @@ static int __init init_acpi_pm_clocksource(void)
 		if (i == ACPI_PM_READ_CHECKS) {
 			printk(KERN_INFO "PM-Timer failed consistency check "
 			       " (0x%#llx) - aborting.\n", value1);
+			pmtmr_ioport = 0;
 			return -ENODEV;
 		}
 	}

^ permalink raw reply related	[flat|nested] 24+ messages in thread

* Re: [tip:x86/tsc] x86: Improve TSC calibration using a delayed workqueue
  2011-01-13 17:49             ` Konrad Rzeszutek Wilk
@ 2011-01-13 18:01               ` john stultz
  2011-01-13 21:40                 ` [PATCH] acpi/pm: If failed at validating ACPI PM timer, inhibit future reads Konrad Rzeszutek Wilk
  0 siblings, 1 reply; 24+ messages in thread
From: john stultz @ 2011-01-13 18:01 UTC (permalink / raw)
  To: Konrad Rzeszutek Wilk
  Cc: Kirill A. Shutemov, Jeremy Fitzhardinge, Stefano Stabellini,
	Ian Campbell, Thomas Gleixner, mingo, hpa, linux-kernel, andi,
	williams, schwidefsky, mingo, linux-tip-commits

On Thu, 2011-01-13 at 12:49 -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 11, 2011 at 11:56:40AM +0200, Kirill A. Shutemov wrote:
> > On Tue, Jan 11, 2011 at 09:37:15AM +0100, Thomas Gleixner wrote:
> > > On Tue, 11 Jan 2011, Kirill A. Shutemov wrote:
> > > 
> > > > On Tue, Jan 11, 2011 at 09:26:48AM +0100, Thomas Gleixner wrote:
> > > > > On Tue, 11 Jan 2011, Kirill A. Shutemov wrote:
> > > > > 
> > > > > > On Sun, Dec 05, 2010 at 11:18:53AM +0000, tip-bot for John Stultz wrote:
> > > > > > > Commit-ID:  08ec0c58fb8a05d3191d5cb6f5d6f81adb419798
> > > > > > > Gitweb:     http://git.kernel.org/tip/08ec0c58fb8a05d3191d5cb6f5d6f81adb419798
> > > > > > > Author:     John Stultz <johnstul@us.ibm.com>
> > > > > > > AuthorDate: Tue, 27 Jul 2010 17:00:00 -0700
> > > > > > > Committer:  John Stultz <john.stultz@linaro.org>
> > > > > > > CommitDate: Thu, 2 Dec 2010 16:48:37 -0800
> > > > > > > 
> > > > > > > x86: Improve TSC calibration using a delayed workqueue
> > > > > > 
> > > > > > This commit breaks booting the kernel in qemu with enabled KVM on my machine.
> > > > > > .config attached.
> > > > > > 
> > > > > > [    0.424013] divide error: 0000 [#1] 
> > > > > 
> > > > > Got fixed by a8760ec (x86: Check tsc available/disabled in the delayed
> > > > > init function)
> > > > 
> > > > No, it didn't. :(
> > > > 
> > > > I am able to reproduce it on current Linus' tree (v2.6.37-4700-g8adbf8d).
> > > 
> > > Does the patch below fix it ? We can end up with tsc_khz=0 there :(
> > 
> > Yes, it does.
> 
> Interestingly enough, when you run Linux under Xen (as Domain 0) you
> get the same stack-trace. With both patches (a8760ec, and the patch
> posted earlier) I still get the failure.
> 
> I've traced it down to the fact that when we boot under Xen we do
> not have the HPET enabled nor the ACPI PM timer setup. The 
> hpet_enable() is never called (b/c xen_time_init is called), and
> for calibration of tsc_khz (calibrate_tsc == xen_tsc_khz) we
> get a valid value.
> 
> So 'tsc_read_refs' tries to read the ACPI PM timer (acpi_pm_read_early),
> however that is disabled under Xen:
> 
> [    1.099272] calling  init_acpi_pm_clocksource+0x0/0xdc @ 1
> [    1.140186] PM-Timer failed consistency check  (0x0xffffff) - aborting.
> 
> So the tsc_calibrate_check gets called, it can't do HPET, and reading
> from ACPI PM timer results in getting 0xffffff.. .. and
> (0xffff..-0xffff..)/some other value results in div_zero.
> 
> There is a check in 'tsc_refine_calibration_work' for invalid
> values:
> 
>    /* hpet or pmtimer available ? */
>          if (!hpet && !ref_start && !ref_stop)
>                   goto out;
> 
> But since ref_start and ref_stop have 0xffffff it does not trigger.

Oof. Thanks for hunting this down!

> This little fix does it however. Thought it will of course not
> recalibrate the tsc - is that a horrible thing? Should we look
> at making tsc_read_refs also use the pv-ops in case both hpet and
> acpi pm timer are disabled?

The recalibration is not a necessary thing. Its only an improvement over
what the standard calibration we have always done is. Since xen provides
its own xen_tsc_khz value, I suspect the timer based
calibration-refinement might not improve over what xen provides.


> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Acked-by: John Stultz <johnstul@us.ibm.com>

> diff --git a/drivers/clocksource/acpi_pm.c b/drivers/clocksource/acpi_pm.c
> index cfb0f52..84ff897 100644
> --- a/drivers/clocksource/acpi_pm.c
> +++ b/drivers/clocksource/acpi_pm.c
> @@ -207,6 +208,7 @@ static int __init init_acpi_pm_clocksource(void)
>  		if (i == ACPI_PM_READ_CHECKS) {
>  			printk(KERN_INFO "PM-Timer failed consistency check "
>  			       " (0x%#llx) - aborting.\n", value1);
> +			pmtmr_ioport = 0;
>  			return -ENODEV;
>  		}
>  	}



^ permalink raw reply	[flat|nested] 24+ messages in thread

* [PATCH] acpi/pm: If failed at validating ACPI PM timer, inhibit future reads.
  2011-01-13 18:01               ` john stultz
@ 2011-01-13 21:40                 ` Konrad Rzeszutek Wilk
  2011-01-13 22:15                   ` Thomas Gleixner
  0 siblings, 1 reply; 24+ messages in thread
From: Konrad Rzeszutek Wilk @ 2011-01-13 21:40 UTC (permalink / raw)
  To: john stultz, Thomas Gleixner
  Cc: Kirill A. Shutemov, Jeremy Fitzhardinge, Stefano Stabellini,
	Ian Campbell, Thomas Gleixner, mingo, hpa, linux-kernel, andi,
	williams, schwidefsky, mingo, linux-tip-commits

tgl, John,

Should I push this to Linus or are you guys going to push
this patch during this merge window?

commit ad0a17d46570aca172080016601813173a778fb7
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Thu Jan 13 12:56:51 2011 -0500

    acpi/pm: If failed at validating ACPI PM timer, inhibit future reads.
    
    Without this patch we get:
    [    4.628136] divide error: 0000 [#1] SMP
    .. snip..
    Pid: 441, comm: kworker/1:1 Not tainted 2.6.37test-05765-gda43a99-dirty #14 N61PB-M2S/N61PB-M2S
    [    4.628150] RIP: e030:[<ffffffff8101109b>]  [<ffffffff8101109b>] tsc_refine_calibration_work+0x149/0x1bb
    [    4.628157] RSP: e02b:ffff88008f0d1df0  EFLAGS: 00010246
    .. when running Linux under Xen.
    
    I've traced it down to the fact that when we boot under Xen we do
    not have the HPET enabled nor the ACPI PM timer setup. The
    hpet_enable() is never called (b/c xen_time_init is called), and
    for calibration of tsc_khz (calibrate_tsc == xen_tsc_khz) we
    get a valid value.
    
    So 'tsc_read_refs' tries to read the ACPI PM timer (acpi_pm_read_early),
    however that is disabled under Xen:
    
    [    1.099272] calling  init_acpi_pm_clocksource+0x0/0xdc @ 1
    [    1.140186] PM-Timer failed consistency check  (0x0xffffff) - aborting.
    
    So the tsc_calibrate_check gets called, it can't do HPET, and reading
    from ACPI PM timer results in getting 0xffffff.. .. and
    (0xffff..-0xffff..)/some other value results in div_zero.
    
    There is a check in 'tsc_refine_calibration_work' for invalid
    values:
    
       /* hpet or pmtimer available ? */
             if (!hpet && !ref_start && !ref_stop)
                      goto out;
    
    But since ref_start and ref_stop have 0xffffff it does not trigger.
    
    This little fix makes the read to be 0 and the check triggers.
    
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Acked-by: John Stultz <johnstul@us.ibm.com>

diff --git a/drivers/clocksource/acpi_pm.c b/drivers/clocksource/acpi_pm.c
index cfb0f52..709bb6d 100644
--- a/drivers/clocksource/acpi_pm.c
+++ b/drivers/clocksource/acpi_pm.c
@@ -207,6 +207,7 @@ static int __init init_acpi_pm_clocksource(void)
 		if (i == ACPI_PM_READ_CHECKS) {
 			printk(KERN_INFO "PM-Timer failed consistency check "
 			       " (0x%#llx) - aborting.\n", value1);
+			pmtmr_ioport = 0;
 			return -ENODEV;
 		}
 	}

^ permalink raw reply related	[flat|nested] 24+ messages in thread

* Re: [PATCH] acpi/pm: If failed at validating ACPI PM timer, inhibit future reads.
  2011-01-13 21:40                 ` [PATCH] acpi/pm: If failed at validating ACPI PM timer, inhibit future reads Konrad Rzeszutek Wilk
@ 2011-01-13 22:15                   ` Thomas Gleixner
  2011-01-14 14:09                     ` Konrad Rzeszutek Wilk
  0 siblings, 1 reply; 24+ messages in thread
From: Thomas Gleixner @ 2011-01-13 22:15 UTC (permalink / raw)
  To: Konrad Rzeszutek Wilk
  Cc: john stultz, Kirill A. Shutemov, Jeremy Fitzhardinge,
	Stefano Stabellini, Ian Campbell, mingo, hpa, linux-kernel, andi,
	williams, schwidefsky, mingo, linux-tip-commits

On Thu, 13 Jan 2011, Konrad Rzeszutek Wilk wrote:

> tgl, John,
> 
> Should I push this to Linus or are you guys going to push
> this patch during this merge window?

Wait a moment. This patch is fresh of the press and not that urgent,
really.
 
>     I've traced it down to the fact that when we boot under Xen we do
>     not have the HPET enabled nor the ACPI PM timer setup. The

Crap. If Xen would not have setup the pm timer then it would not even
reach the consistency check. It would simply bail out via

        if (!pmtmr_ioport)
                return -ENODEV;

and the whole misery would not have happened at all. Though it's a
Good Thing that Xen is so screwed as it points to a real flaw which
might happen on real hardware as well. See below

>     hpet_enable() is never called (b/c xen_time_init is called), and
>     for calibration of tsc_khz (calibrate_tsc == xen_tsc_khz) we
>     get a valid value.
>     
>     So 'tsc_read_refs' tries to read the ACPI PM timer (acpi_pm_read_early),
>     however that is disabled under Xen:
>     
>     [    1.099272] calling  init_acpi_pm_clocksource+0x0/0xdc @ 1
>     [    1.140186] PM-Timer failed consistency check  (0x0xffffff) - aborting.
>     
>     So the tsc_calibrate_check gets called, it can't do HPET, and reading
>     from ACPI PM timer results in getting 0xffffff.. .. and
>     (0xffff..-0xffff..)/some other value results in div_zero.

Nonsense. 0/(some other value) does not result in a divide by zero
except "some other value" is zero.

>     There is a check in 'tsc_refine_calibration_work' for invalid
>     values:
>     
>        /* hpet or pmtimer available ? */
>              if (!hpet && !ref_start && !ref_stop)
>                       goto out;
>     
>     But since ref_start and ref_stop have 0xffffff it does not trigger.
>
>     This little fix makes the read to be 0 and the check triggers.

First of all the patch disables the pm_timer completely, which happens
to results in a 0 read as a side effect. But the main point of this
fix is to disable pmtimer in case of failure in the init function
completely.

Further there are several error conditions in this init function and
we really need to disable pmtimer for all of them not just for the
case you encountered.

Thanks,

	tglx

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] acpi/pm: If failed at validating ACPI PM timer, inhibit future reads.
  2011-01-13 22:15                   ` Thomas Gleixner
@ 2011-01-14 14:09                     ` Konrad Rzeszutek Wilk
  2011-01-14 15:44                       ` john stultz
  0 siblings, 1 reply; 24+ messages in thread
From: Konrad Rzeszutek Wilk @ 2011-01-14 14:09 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: john stultz, Kirill A. Shutemov, Jeremy Fitzhardinge,
	Stefano Stabellini, Ian Campbell, mingo, hpa, linux-kernel, andi,
	williams, schwidefsky, mingo, linux-tip-commits

On Thu, Jan 13, 2011 at 11:15:16PM +0100, Thomas Gleixner wrote:
> On Thu, 13 Jan 2011, Konrad Rzeszutek Wilk wrote:
> 
> > tgl, John,
> > 
> > Should I push this to Linus or are you guys going to push
> > this patch during this merge window?
> 
> Wait a moment. This patch is fresh of the press and not that urgent,
> really.

It is a regression compared to 2.6.37 kernel. I don't know the
urgency requirements for regressions but I figured the earlier the
better.

>  
> >     I've traced it down to the fact that when we boot under Xen we do
> >     not have the HPET enabled nor the ACPI PM timer setup. The
> 
> Crap. If Xen would not have setup the pm timer then it would not even
> reach the consistency check. It would simply bail out via

Keep in mind that Linux (under Xen) does see the ACPI PM-Timer at bootup
(it parses the ACPI tables), and when it tries to actually read the 
values, so past this point:

> 
>         if (!pmtmr_ioport)
>                 return -ENODEV;
> 

.. it fails at:
   if (i == ACPI_PM_READ_CHECKS) {

and returns -ENODEV. So pmtmr_ioport was still valid at that time.

> and the whole misery would not have happened at all. Though it's a
> Good Thing that Xen is so screwed as it points to a real flaw which
> might happen on real hardware as well. See below
> 
> >     hpet_enable() is never called (b/c xen_time_init is called), and
> >     for calibration of tsc_khz (calibrate_tsc == xen_tsc_khz) we
> >     get a valid value.
> >     
> >     So 'tsc_read_refs' tries to read the ACPI PM timer (acpi_pm_read_early),
> >     however that is disabled under Xen:
> >     
> >     [    1.099272] calling  init_acpi_pm_clocksource+0x0/0xdc @ 1
> >     [    1.140186] PM-Timer failed consistency check  (0x0xffffff) - aborting.
> >     
> >     So the tsc_calibrate_check gets called, it can't do HPET, and reading
> >     from ACPI PM timer results in getting 0xffffff.. .. and
> >     (0xffff..-0xffff..)/some other value results in div_zero.
> 
> Nonsense. 0/(some other value) does not result in a divide by zero
> except "some other value" is zero.

<scratches his head> You are right. 
> 
> >     There is a check in 'tsc_refine_calibration_work' for invalid
> >     values:
> >     
> >        /* hpet or pmtimer available ? */
> >              if (!hpet && !ref_start && !ref_stop)
> >                       goto out;
> >     
> >     But since ref_start and ref_stop have 0xffffff it does not trigger.
> >
> >     This little fix makes the read to be 0 and the check triggers.
> 
> First of all the patch disables the pm_timer completely, which happens
> to results in a 0 read as a side effect. But the main point of this

I does not look like a side-effect. Specifically:

static inline u32 acpi_pm_read_early(void)
{
        if (!pmtmr_ioport)
                return 0;

	 return acpi_pm_read_verified() & ACPI_PM_MASK;
}

.. ends up taking the !pmtmr_ioport path which is what
tsc_refine_calibration_work has a check for.

> fix is to disable pmtimer in case of failure in the init function
> completely.
> 
> Further there are several error conditions in this init function and
> we really need to disable pmtimer for all of them not just for the
> case you encountered.

Good point. What about this patch? John, is it OK if I carry
your Ack-by on this modified patch?

commit 7b530022a59683b3164404ee8ee2d5750748b58b
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Thu Jan 13 12:56:51 2011 -0500

    acpi/pm: If failed at validating ACPI PM timer, inhibit future reads.
    
    Without this patch we get:
    [    4.628136] divide error: 0000 [#1] SMP
    .. snip..
    Pid: 441, comm: kworker/1:1 Not tainted 2.6.37test-05765-gda43a99-dirty #14 N61PB-M2S/N61PB-M2S
    [    4.628150] RIP: e030:[<ffffffff8101109b>]  [<ffffffff8101109b>] tsc_refine_calibration_work+0x149/0x1bb
    [    4.628157] RSP: e02b:ffff88008f0d1df0  EFLAGS: 00010246
    .. when running Linux under Xen.
    
    I've traced it down to the fact that when we boot under Xen we do
    not have the HPET enabled nor the ACPI PM timer setup properly
    (it is however detected earlier, so pmtmr_ioport is correct).
    The hpet_enable() is never called (b/c xen_time_init is called), and
    for calibration of tsc_khz (calibrate_tsc == xen_tsc_khz) we
    get a valid value.
    
    So 'tsc_read_refs' tries to read the ACPI PM timer (acpi_pm_read_early),
    however that is disabled under Xen:
    
    [    1.099272] calling  init_acpi_pm_clocksource+0x0/0xdc @ 1
    [    1.140186] PM-Timer failed consistency check  (0x0xffffff) - aborting.
    
    So the tsc_calibrate_check gets called, it can't do HPET, and reading
    from ACPI PM timer results in getting 0xffffff.. which is invalid.
    
    There is a check in 'tsc_refine_calibration_work' for invalid
    values:
    
       /* hpet or pmtimer available ? */
             if (!hpet && !ref_start && !ref_stop)
                      goto out;
    
    But since ref_start and ref_stop have 0xffffff it does not trigger.
    
    This little fix does it however.
    
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Acked-by: John Stultz <johnstul@us.ibm.com>

diff --git a/drivers/clocksource/acpi_pm.c b/drivers/clocksource/acpi_pm.c
index cfb0f52..02e0f28 100644
--- a/drivers/clocksource/acpi_pm.c
+++ b/drivers/clocksource/acpi_pm.c
@@ -207,12 +207,15 @@ static int __init init_acpi_pm_clocksource(void)
 		if (i == ACPI_PM_READ_CHECKS) {
 			printk(KERN_INFO "PM-Timer failed consistency check "
 			       " (0x%#llx) - aborting.\n", value1);
+			pmtmr_ioport = 0;
 			return -ENODEV;
 		}
 	}
 
-	if (verify_pmtmr_rate() != 0)
+	if (verify_pmtmr_rate() != 0) {
+		pmtmr_ioport = 0;
 		return -ENODEV;
+	}
 
 	return clocksource_register_hz(&clocksource_acpi_pm,
 						PMTMR_TICKS_PER_SEC);

^ permalink raw reply related	[flat|nested] 24+ messages in thread

* Re: [PATCH] acpi/pm: If failed at validating ACPI PM timer, inhibit future reads.
  2011-01-14 14:09                     ` Konrad Rzeszutek Wilk
@ 2011-01-14 15:44                       ` john stultz
  2011-01-14 15:54                         ` john stultz
  0 siblings, 1 reply; 24+ messages in thread
From: john stultz @ 2011-01-14 15:44 UTC (permalink / raw)
  To: Konrad Rzeszutek Wilk
  Cc: Thomas Gleixner, Kirill A. Shutemov, Jeremy Fitzhardinge,
	Stefano Stabellini, Ian Campbell, mingo, hpa, linux-kernel, andi,
	williams, schwidefsky, mingo, linux-tip-commits

On Fri, 2011-01-14 at 09:09 -0500, Konrad Rzeszutek Wilk wrote:
> On Thu, Jan 13, 2011 at 11:15:16PM +0100, Thomas Gleixner wrote:
> > On Thu, 13 Jan 2011, Konrad Rzeszutek Wilk wrote:
> > 
> > > tgl, John,
> > > 
> > > Should I push this to Linus or are you guys going to push
> > > this patch during this merge window?
> > 
> > Wait a moment. This patch is fresh of the press and not that urgent,
> > really.
> 
> It is a regression compared to 2.6.37 kernel. I don't know the
> urgency requirements for regressions but I figured the earlier the
> better.
> 
> >  
> > >     I've traced it down to the fact that when we boot under Xen we do
> > >     not have the HPET enabled nor the ACPI PM timer setup. The
> > 
> > Crap. If Xen would not have setup the pm timer then it would not even
> > reach the consistency check. It would simply bail out via
> 
> Keep in mind that Linux (under Xen) does see the ACPI PM-Timer at bootup
> (it parses the ACPI tables), and when it tries to actually read the 
> values, so past this point:
> 
> > 
> >         if (!pmtmr_ioport)
> >                 return -ENODEV;
> > 
> 
> .. it fails at:
>    if (i == ACPI_PM_READ_CHECKS) {
> 
> and returns -ENODEV. So pmtmr_ioport was still valid at that time.
> 
> > and the whole misery would not have happened at all. Though it's a
> > Good Thing that Xen is so screwed as it points to a real flaw which
> > might happen on real hardware as well. See below
> > 
> > >     hpet_enable() is never called (b/c xen_time_init is called), and
> > >     for calibration of tsc_khz (calibrate_tsc == xen_tsc_khz) we
> > >     get a valid value.
> > >     
> > >     So 'tsc_read_refs' tries to read the ACPI PM timer (acpi_pm_read_early),
> > >     however that is disabled under Xen:
> > >     
> > >     [    1.099272] calling  init_acpi_pm_clocksource+0x0/0xdc @ 1
> > >     [    1.140186] PM-Timer failed consistency check  (0x0xffffff) - aborting.
> > >     
> > >     So the tsc_calibrate_check gets called, it can't do HPET, and reading
> > >     from ACPI PM timer results in getting 0xffffff.. .. and
> > >     (0xffff..-0xffff..)/some other value results in div_zero.
> > 
> > Nonsense. 0/(some other value) does not result in a divide by zero
> > except "some other value" is zero.
> 
> <scratches his head> You are right. 

The (0xffff - 0xffff) bit ends up as the divisor in calc_pmtmr_ref.

> > 
> > >     There is a check in 'tsc_refine_calibration_work' for invalid
> > >     values:
> > >     
> > >        /* hpet or pmtimer available ? */
> > >              if (!hpet && !ref_start && !ref_stop)
> > >                       goto out;
> > >     
> > >     But since ref_start and ref_stop have 0xffffff it does not trigger.
> > >
> > >     This little fix makes the read to be 0 and the check triggers.
> > 
> > First of all the patch disables the pm_timer completely, which happens
> > to results in a 0 read as a side effect. But the main point of this
> 
> I does not look like a side-effect. Specifically:
> 
> static inline u32 acpi_pm_read_early(void)
> {
>         if (!pmtmr_ioport)
>                 return 0;
> 
> 	 return acpi_pm_read_verified() & ACPI_PM_MASK;
> }
> 
> .. ends up taking the !pmtmr_ioport path which is what
> tsc_refine_calibration_work has a check for.
> 
> > fix is to disable pmtimer in case of failure in the init function
> > completely.
> > 
> > Further there are several error conditions in this init function and
> > we really need to disable pmtimer for all of them not just for the
> > case you encountered.
> 
> Good point. What about this patch? John, is it OK if I carry
> your Ack-by on this modified patch?

I'm actually looking at a different fix, as I'm worried by Thomas'
comment about hitting the same issue on real hardware if we catch the
same pmtrm value both times.

thanks
-john





^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] acpi/pm: If failed at validating ACPI PM timer, inhibit future reads.
  2011-01-14 15:44                       ` john stultz
@ 2011-01-14 15:54                         ` john stultz
  2011-01-14 16:02                           ` Thomas Gleixner
  2011-01-14 16:28                           ` Konrad Rzeszutek Wilk
  0 siblings, 2 replies; 24+ messages in thread
From: john stultz @ 2011-01-14 15:54 UTC (permalink / raw)
  To: Konrad Rzeszutek Wilk
  Cc: Thomas Gleixner, Kirill A. Shutemov, Jeremy Fitzhardinge,
	Stefano Stabellini, Ian Campbell, mingo, hpa, linux-kernel, andi,
	williams, schwidefsky, mingo, linux-tip-commits

On Fri, 2011-01-14 at 07:44 -0800, john stultz wrote:
> I'm actually looking at a different fix, as I'm worried by Thomas'
> comment about hitting the same issue on real hardware if we catch the
> same pmtrm value both times.

Konrad: Mind trying the following?


The conditional (!hpet && !ref_start && !ref_stop) doesn't really make
sense. If the refs are null, but hpet is on, we still want to break out.

So checking if both the ref values are the same should handle if we
don't have hardware (both null) or if they are the same value (either by
invalid hardware, or by chance), which can cause a divzero issue.

NOT FOR INCLUSION, I haven't had my coffee yet.
Signed-off-by: John Stultz <johnstul@us.ibm.com>

diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 823f79a..fa2cb5e 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -935,7 +935,7 @@ static void tsc_refine_calibration_work(struct work_struct *work)
 	tsc_stop = tsc_read_refs(&ref_stop, hpet);
 
 	/* hpet or pmtimer available ? */
-	if (!hpet && !ref_start && !ref_stop)
+	if (ref_start == ref_stop)
 		goto out;
 
 	/* Check, whether the sampling was disturbed by an SMI */





^ permalink raw reply related	[flat|nested] 24+ messages in thread

* Re: [PATCH] acpi/pm: If failed at validating ACPI PM timer, inhibit future reads.
  2011-01-14 15:54                         ` john stultz
@ 2011-01-14 16:02                           ` Thomas Gleixner
  2011-01-14 16:33                             ` john stultz
  2011-01-14 16:28                           ` Konrad Rzeszutek Wilk
  1 sibling, 1 reply; 24+ messages in thread
From: Thomas Gleixner @ 2011-01-14 16:02 UTC (permalink / raw)
  To: john stultz
  Cc: Konrad Rzeszutek Wilk, Kirill A. Shutemov, Jeremy Fitzhardinge,
	Stefano Stabellini, Ian Campbell, mingo, hpa, linux-kernel, andi,
	williams, schwidefsky, mingo, linux-tip-commits

On Fri, 14 Jan 2011, john stultz wrote:

> On Fri, 2011-01-14 at 07:44 -0800, john stultz wrote:
> > I'm actually looking at a different fix, as I'm worried by Thomas'
> > comment about hitting the same issue on real hardware if we catch the
> > same pmtrm value both times.
> 
> Konrad: Mind trying the following?
> 
> 
> The conditional (!hpet && !ref_start && !ref_stop) doesn't really make
> sense. If the refs are null, but hpet is on, we still want to break out.
> 
> So checking if both the ref values are the same should handle if we
> don't have hardware (both null) or if they are the same value (either by
> invalid hardware, or by chance), which can cause a divzero issue.
> 
> NOT FOR INCLUSION, I haven't had my coffee yet.
> Signed-off-by: John Stultz <johnstul@us.ibm.com>
> 
> diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
> index 823f79a..fa2cb5e 100644
> --- a/arch/x86/kernel/tsc.c
> +++ b/arch/x86/kernel/tsc.c
> @@ -935,7 +935,7 @@ static void tsc_refine_calibration_work(struct work_struct *work)
>  	tsc_stop = tsc_read_refs(&ref_stop, hpet);
>  
>  	/* hpet or pmtimer available ? */
> -	if (!hpet && !ref_start && !ref_stop)
> +	if (ref_start == ref_stop)
>  		goto out;
>  
>  	/* Check, whether the sampling was disturbed by an SMI */

That makes sense, though we really should kill pmtimer when we detect
that it's crappy.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] acpi/pm: If failed at validating ACPI PM timer, inhibit future reads.
  2011-01-14 15:54                         ` john stultz
  2011-01-14 16:02                           ` Thomas Gleixner
@ 2011-01-14 16:28                           ` Konrad Rzeszutek Wilk
  1 sibling, 0 replies; 24+ messages in thread
From: Konrad Rzeszutek Wilk @ 2011-01-14 16:28 UTC (permalink / raw)
  To: john stultz
  Cc: Thomas Gleixner, Kirill A. Shutemov, Jeremy Fitzhardinge,
	Stefano Stabellini, Ian Campbell, mingo, hpa, linux-kernel, andi,
	williams, schwidefsky, mingo, linux-tip-commits

On Fri, Jan 14, 2011 at 07:54:47AM -0800, john stultz wrote:
> On Fri, 2011-01-14 at 07:44 -0800, john stultz wrote:
> > I'm actually looking at a different fix, as I'm worried by Thomas'
> > comment about hitting the same issue on real hardware if we catch the
> > same pmtrm value both times.
> 
> Konrad: Mind trying the following?
> 
> 
> The conditional (!hpet && !ref_start && !ref_stop) doesn't really make
> sense. If the refs are null, but hpet is on, we still want to break out.
> 
> So checking if both the ref values are the same should handle if we
> don't have hardware (both null) or if they are the same value (either by
> invalid hardware, or by chance), which can cause a divzero issue.
> 
> NOT FOR INCLUSION, I haven't had my coffee yet.
> Signed-off-by: John Stultz <johnstul@us.ibm.com>

Works great. (I pulled out my patch to test this).

Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

> 
> diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
> index 823f79a..fa2cb5e 100644
> --- a/arch/x86/kernel/tsc.c
> +++ b/arch/x86/kernel/tsc.c
> @@ -935,7 +935,7 @@ static void tsc_refine_calibration_work(struct work_struct *work)
>  	tsc_stop = tsc_read_refs(&ref_stop, hpet);
>  
>  	/* hpet or pmtimer available ? */
> -	if (!hpet && !ref_start && !ref_stop)
> +	if (ref_start == ref_stop)
>  		goto out;
>  
>  	/* Check, whether the sampling was disturbed by an SMI */
> 
> 
> 

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] acpi/pm: If failed at validating ACPI PM timer, inhibit future reads.
  2011-01-14 16:02                           ` Thomas Gleixner
@ 2011-01-14 16:33                             ` john stultz
  0 siblings, 0 replies; 24+ messages in thread
From: john stultz @ 2011-01-14 16:33 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Konrad Rzeszutek Wilk, Kirill A. Shutemov, Jeremy Fitzhardinge,
	Stefano Stabellini, Ian Campbell, mingo, hpa, linux-kernel, andi,
	williams, schwidefsky, mingo, linux-tip-commits

On Fri, 2011-01-14 at 17:02 +0100, Thomas Gleixner wrote:
> On Fri, 14 Jan 2011, john stultz wrote:
> 
> > On Fri, 2011-01-14 at 07:44 -0800, john stultz wrote:
> > > I'm actually looking at a different fix, as I'm worried by Thomas'
> > > comment about hitting the same issue on real hardware if we catch the
> > > same pmtrm value both times.
> > 
> > Konrad: Mind trying the following?
> > 
> > 
> > The conditional (!hpet && !ref_start && !ref_stop) doesn't really make
> > sense. If the refs are null, but hpet is on, we still want to break out.
> > 
> > So checking if both the ref values are the same should handle if we
> > don't have hardware (both null) or if they are the same value (either by
> > invalid hardware, or by chance), which can cause a divzero issue.
> > 
> > NOT FOR INCLUSION, I haven't had my coffee yet.
> > Signed-off-by: John Stultz <johnstul@us.ibm.com>
> > 
> > diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
> > index 823f79a..fa2cb5e 100644
> > --- a/arch/x86/kernel/tsc.c
> > +++ b/arch/x86/kernel/tsc.c
> > @@ -935,7 +935,7 @@ static void tsc_refine_calibration_work(struct work_struct *work)
> >  	tsc_stop = tsc_read_refs(&ref_stop, hpet);
> >  
> >  	/* hpet or pmtimer available ? */
> > -	if (!hpet && !ref_start && !ref_stop)
> > +	if (ref_start == ref_stop)
> >  		goto out;
> >  
> >  	/* Check, whether the sampling was disturbed by an SMI */
> 
> That makes sense, though we really should kill pmtimer when we detect
> that it's crappy.

Agreed. 

thanks
-john


^ permalink raw reply	[flat|nested] 24+ messages in thread

* [PATCH] Greatly improve TSC calibration using a delayed workqueue
@ 2010-11-10 21:51 John Stultz
  0 siblings, 0 replies; 24+ messages in thread
From: John Stultz @ 2010-11-10 21:51 UTC (permalink / raw)
  To: LKML
  Cc: John Stultz, Thomas Gleixner, Ingo Molnar, Martin Schwidefsky,
	Clark Williams, Andi Kleen

Boot to boot the TSC calibration may vary by quite a large amount.

While normal variance of 50-100ppm can easily be seen, the quick
calibration code only requires 500ppm accuracy, which is the limit
of what NTP can correct for.

This can cause problems for systems being used as NTP servers, as
every time they reboot it can take hours for them to calculate the
new drift error caused by the calibration.

The classic trade-off here is calibration accuracy vs slow boot times,
as during the calibration nothing else can run.

This patch uses a delayed workqueue  to calibrate the TSC over the
period of a second. This allows very accurate calibration (in my
tests only varying by 1khz or 0.4ppm boot to boot). Additionally this
refined calibration step does not block the boot process, and only
delays the TSC clocksoure registration by a few seconds in early boot.
If the refined calibration strays 1% from the early boot calibration
value, the system will fall back to already calculated early boot
calibration.

Credit to Andi Kleen who suggested using a timer quite awhile back,
but I dismissed it thinking the timer calibration would be done after
the clocksource was registered (which would break things). Forgive
me for my short-sightedness.

This patch has worked very well in my testing, but TSC hardware is
quite varied so it would probably be good to get some extended
testing, possibly pushing inclusion out to 2.6.39.

Signed-off-by: John Stultz <johnstul@us.ibm.com>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Ingo Molnar <mingo@elte.hu>
CC: Martin Schwidefsky <schwidefsky@de.ibm.com>
CC: Clark Williams <williams@redhat.com>
CC: Andi Kleen <andi@firstfloor.org>
---
 arch/x86/kernel/tsc.c |   86 +++++++++++++++++++++++++++++++++++++++++++++++--
 1 files changed, 83 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 0c40d8b..b6ae293 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -885,7 +885,82 @@ __cpuinit int unsynchronized_tsc(void)
 	return tsc_unstable;
 }
 
-static void __init init_tsc_clocksource(void)
+
+static void tsc_refine_calibration_work(struct work_struct *work);
+static DECLARE_DELAYED_WORK(tsc_irqwork, tsc_refine_calibration_work);
+/**
+ * tsc_refine_calibration_work - Further refine tsc freq calibration
+ * @work - ignored.
+ *
+ * This functions uses delayed work over a period of a
+ * second to further refine the TSC freq value. Since this is
+ * timer based, instead of loop based, we don't block the boot
+ * process while this longer calibration is done.
+ *
+ * If there are any calibration anomolies (too many SMIs, etc),
+ * or the refined calibration is off by 1% of the fast early
+ * calibration, we throw out the new calibration and use the
+ * early calibration.
+ */
+static void tsc_refine_calibration_work(struct work_struct *work)
+{
+	static u64 tsc_start = -1, ref_start;
+	static int hpet;
+	u64 tsc_stop, ref_stop, delta;
+	unsigned long freq;
+
+	/* Don't bother refining TSC on unstable systems */
+	if (check_tsc_unstable())
+		goto out;
+
+	/*
+	 * Since the work is started early in boot, we may be
+	 * delayed the first time we expire. So set the workqueue
+	 * again once we know timers are working.
+	 */
+	if (tsc_start == -1) {
+		/*
+		 * Only set hpet once, to avoid mixing hardware
+		 * if the hpet becomes enabled later.
+		 */
+		hpet = is_hpet_enabled();
+		schedule_delayed_work(&tsc_irqwork, HZ);
+		tsc_start = tsc_read_refs(&ref_start, hpet);
+		return;
+	}
+
+	tsc_stop = tsc_read_refs(&ref_stop, hpet);
+
+	/* hpet or pmtimer available ? */
+	if (!hpet && !ref_start && !ref_stop)
+		goto out;
+
+	/* Check, whether the sampling was disturbed by an SMI */
+	if (tsc_start == ULLONG_MAX || tsc_stop == ULLONG_MAX)
+		goto out;
+
+	delta = tsc_stop - tsc_start;
+	delta *= 1000000LL;
+	if (hpet)
+		freq = calc_hpet_ref(delta, ref_start, ref_stop);
+	else
+		freq = calc_pmtimer_ref(delta, ref_start, ref_stop);
+
+	/* Make sure we're within 1% */
+	if (abs(tsc_khz - freq) > tsc_khz/100)
+		goto out;
+
+	tsc_khz = freq;
+	printk(KERN_INFO "Refined TSC clocksource calibration: "
+		"%lu.%03lu MHz.\n", (unsigned long)tsc_khz / 1000,
+					(unsigned long)tsc_khz % 1000);
+
+out:
+	clocksource_register_khz(&clocksource_tsc, tsc_khz);
+}
+
+
+static int __init init_tsc_clocksource(void)
 {
 	if (tsc_clocksource_reliable)
 		clocksource_tsc.flags &= ~CLOCK_SOURCE_MUST_VERIFY;
@@ -894,8 +969,14 @@ static void __init init_tsc_clocksource(void)
 		clocksource_tsc.rating = 0;
 		clocksource_tsc.flags &= ~CLOCK_SOURCE_IS_CONTINUOUS;
 	}
-	clocksource_register_khz(&clocksource_tsc, tsc_khz);
+	schedule_delayed_work(&tsc_irqwork, 0);
+	return 0;
 }
+/*
+ * We use device_initcall here, to ensure we run after the hpet
+ * is fully initialized, which may occur at fs_initcall time.
+ */
+device_initcall(init_tsc_clocksource);
 
 void __init tsc_init(void)
 {
@@ -949,6 +1030,5 @@ void __init tsc_init(void)
 		mark_tsc_unstable("TSCs unsynchronized");
 
 	check_system_tsc_reliable();
-	init_tsc_clocksource();
 }
 
-- 
1.7.3.2.146.gca209


^ permalink raw reply related	[flat|nested] 24+ messages in thread

end of thread, other threads:[~2011-01-14 16:34 UTC | newest]

Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-11-06  0:39 [PATCH] Greatly improve TSC calibration using a delayed workqueue John Stultz
2010-11-07 20:41 ` Andi Kleen
2010-11-08 22:04   ` john stultz
2010-11-09 13:43     ` Andi Kleen
2010-11-09 21:41       ` john stultz
2010-11-10 13:47         ` Andi Kleen
2010-12-05 11:18 ` [tip:x86/tsc] x86: Improve " tip-bot for John Stultz
2011-01-11  8:13   ` Kirill A. Shutemov
2011-01-11  8:26     ` Thomas Gleixner
2011-01-11  8:30       ` Kirill A. Shutemov
2011-01-11  8:37         ` Thomas Gleixner
2011-01-11  9:56           ` Kirill A. Shutemov
2011-01-11 10:26             ` Thomas Gleixner
2011-01-13 17:49             ` Konrad Rzeszutek Wilk
2011-01-13 18:01               ` john stultz
2011-01-13 21:40                 ` [PATCH] acpi/pm: If failed at validating ACPI PM timer, inhibit future reads Konrad Rzeszutek Wilk
2011-01-13 22:15                   ` Thomas Gleixner
2011-01-14 14:09                     ` Konrad Rzeszutek Wilk
2011-01-14 15:44                       ` john stultz
2011-01-14 15:54                         ` john stultz
2011-01-14 16:02                           ` Thomas Gleixner
2011-01-14 16:33                             ` john stultz
2011-01-14 16:28                           ` Konrad Rzeszutek Wilk
2010-11-10 21:51 [PATCH] Greatly improve TSC calibration using a delayed workqueue John Stultz

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.