All of lore.kernel.org
 help / color / mirror / Atom feed
* 2.6.33: Problem continues: WARNING: at arch/x86/kernel/hpet.c:404 hpet_next_event+0x70/0x80
@ 2010-02-24 23:37 Justin Piszcz
  2010-02-25 14:03 ` Thomas Backlund
  2010-02-25 18:53 ` Pallipadi, Venkatesh
  0 siblings, 2 replies; 7+ messages in thread
From: Justin Piszcz @ 2010-02-24 23:37 UTC (permalink / raw)
  To: linux-kernel

Hello,

Again, on the Intel DP55KG board:

# uname -a
Linux host 2.6.33 #1 SMP Wed Feb 24 18:31:00 EST 2010 x86_64 GNU/Linux

[    1.237600] ------------[ cut here ]------------
[    1.237890] WARNING: at arch/x86/kernel/hpet.c:404 hpet_next_event+0x70/0x80()
[    1.238221] Hardware name:
[    1.238504] hpet: compare register read back failed.
[    1.238793] Modules linked in:
[    1.239315] Pid: 0, comm: swapper Not tainted 2.6.33 #1
[    1.239605] Call Trace:
[    1.239886]  <IRQ>  [<ffffffff81056c13>] ? warn_slowpath_common+0x73/0xb0
[    1.240409]  [<ffffffff81079608>] ? tick_dev_program_event+0x38/0xc0
[    1.240699]  [<ffffffff81056cb0>] ? warn_slowpath_fmt+0x40/0x50
[    1.240992]  [<ffffffff81079608>] ? tick_dev_program_event+0x38/0xc0
[    1.241281]  [<ffffffff81041ad0>] ? hpet_next_event+0x70/0x80
[    1.241573]  [<ffffffff81079608>] ? tick_dev_program_event+0x38/0xc0
[    1.241859]  [<ffffffff81078e32>] ? tick_handle_oneshot_broadcast+0xe2/0x100
[    1.246533]  [<ffffffff8102a67a>] ? timer_interrupt+0x1a/0x30
[    1.246826]  [<ffffffff81085499>] ? handle_IRQ_event+0x39/0xd0
[    1.247118]  [<ffffffff81087368>] ? handle_edge_irq+0xb8/0x160
[    1.247407]  [<ffffffff81029f55>] ? handle_irq+0x15/0x20
[    1.247689]  [<ffffffff810294a2>] ? do_IRQ+0x62/0xe0
[    1.247976]  [<ffffffff8146be53>] ? ret_from_intr+0x0/0xa
[    1.248262]  <EOI>  [<ffffffff8102f277>] ? mwait_idle+0x57/0x80
[    1.248796]  [<ffffffff8102645c>] ? cpu_idle+0x5c/0xb0
[    1.249080] ---[ end trace db7f668fb6fef4e1 ]---

Is this something Intel has to fix or is it a bug in the kernel?

Justin.


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

* Re: 2.6.33: Problem continues: WARNING: at arch/x86/kernel/hpet.c:404 hpet_next_event+0x70/0x80
  2010-02-24 23:37 2.6.33: Problem continues: WARNING: at arch/x86/kernel/hpet.c:404 hpet_next_event+0x70/0x80 Justin Piszcz
@ 2010-02-25 14:03 ` Thomas Backlund
  2010-02-25 14:22   ` Justin Piszcz
  2010-02-25 18:53 ` Pallipadi, Venkatesh
  1 sibling, 1 reply; 7+ messages in thread
From: Thomas Backlund @ 2010-02-25 14:03 UTC (permalink / raw)
  To: Justin Piszcz; +Cc: linux-kernel

Justin Piszcz skrev 25.2.2010 01:37:
> Hello,
>
> Again, on the Intel DP55KG board:
>
> # uname -a
> Linux host 2.6.33 #1 SMP Wed Feb 24 18:31:00 EST 2010 x86_64 GNU/Linux
>
> [ 1.237600] ------------[ cut here ]------------
> [ 1.237890] WARNING: at arch/x86/kernel/hpet.c:404
> hpet_next_event+0x70/0x80()
> [ 1.238221] Hardware name:
> [ 1.238504] hpet: compare register read back failed.
> [ 1.238793] Modules linked in:
> [ 1.239315] Pid: 0, comm: swapper Not tainted 2.6.33 #1
> [ 1.239605] Call Trace:
> [ 1.239886] <IRQ> [<ffffffff81056c13>] ? warn_slowpath_common+0x73/0xb0
> [ 1.240409] [<ffffffff81079608>] ? tick_dev_program_event+0x38/0xc0
> [ 1.240699] [<ffffffff81056cb0>] ? warn_slowpath_fmt+0x40/0x50
> [ 1.240992] [<ffffffff81079608>] ? tick_dev_program_event+0x38/0xc0
> [ 1.241281] [<ffffffff81041ad0>] ? hpet_next_event+0x70/0x80
> [ 1.241573] [<ffffffff81079608>] ? tick_dev_program_event+0x38/0xc0
> [ 1.241859] [<ffffffff81078e32>] ? tick_handle_oneshot_broadcast+0xe2/0x100
> [ 1.246533] [<ffffffff8102a67a>] ? timer_interrupt+0x1a/0x30
> [ 1.246826] [<ffffffff81085499>] ? handle_IRQ_event+0x39/0xd0
> [ 1.247118] [<ffffffff81087368>] ? handle_edge_irq+0xb8/0x160
> [ 1.247407] [<ffffffff81029f55>] ? handle_irq+0x15/0x20
> [ 1.247689] [<ffffffff810294a2>] ? do_IRQ+0x62/0xe0
> [ 1.247976] [<ffffffff8146be53>] ? ret_from_intr+0x0/0xa
> [ 1.248262] <EOI> [<ffffffff8102f277>] ? mwait_idle+0x57/0x80
> [ 1.248796] [<ffffffff8102645c>] ? cpu_idle+0x5c/0xb0
> [ 1.249080] ---[ end trace db7f668fb6fef4e1 ]---
>
> Is this something Intel has to fix or is it a bug in the kernel?
>

Here is a suggested fix:

http://marc.info/?l=linux-kernel&m=126531123524059&w=2

--
Thomas

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

* Re: 2.6.33: Problem continues: WARNING: at arch/x86/kernel/hpet.c:404 hpet_next_event+0x70/0x80
  2010-02-25 14:03 ` Thomas Backlund
@ 2010-02-25 14:22   ` Justin Piszcz
  0 siblings, 0 replies; 7+ messages in thread
From: Justin Piszcz @ 2010-02-25 14:22 UTC (permalink / raw)
  To: Thomas Backlund; +Cc: linux-kernel



On Thu, 25 Feb 2010, Thomas Backlund wrote:

> Justin Piszcz skrev 25.2.2010 01:37:
>> Hello,
>> 
>> Again, on the Intel DP55KG board:
>> 
>> # uname -a
>> Linux host 2.6.33 #1 SMP Wed Feb 24 18:31:00 EST 2010 x86_64 GNU/Linux
>> 
>> [ 1.237600] ------------[ cut here ]------------
>> [ 1.237890] WARNING: at arch/x86/kernel/hpet.c:404
>> hpet_next_event+0x70/0x80()
>> [ 1.238221] Hardware name:
>> [ 1.238504] hpet: compare register read back failed.
>> [ 1.238793] Modules linked in:
>> [ 1.239315] Pid: 0, comm: swapper Not tainted 2.6.33 #1
>> [ 1.239605] Call Trace:
>> [ 1.239886] <IRQ> [<ffffffff81056c13>] ? warn_slowpath_common+0x73/0xb0
>> [ 1.240409] [<ffffffff81079608>] ? tick_dev_program_event+0x38/0xc0
>> [ 1.240699] [<ffffffff81056cb0>] ? warn_slowpath_fmt+0x40/0x50
>> [ 1.240992] [<ffffffff81079608>] ? tick_dev_program_event+0x38/0xc0
>> [ 1.241281] [<ffffffff81041ad0>] ? hpet_next_event+0x70/0x80
>> [ 1.241573] [<ffffffff81079608>] ? tick_dev_program_event+0x38/0xc0
>> [ 1.241859] [<ffffffff81078e32>] ? tick_handle_oneshot_broadcast+0xe2/0x100
>> [ 1.246533] [<ffffffff8102a67a>] ? timer_interrupt+0x1a/0x30
>> [ 1.246826] [<ffffffff81085499>] ? handle_IRQ_event+0x39/0xd0
>> [ 1.247118] [<ffffffff81087368>] ? handle_edge_irq+0xb8/0x160
>> [ 1.247407] [<ffffffff81029f55>] ? handle_irq+0x15/0x20
>> [ 1.247689] [<ffffffff810294a2>] ? do_IRQ+0x62/0xe0
>> [ 1.247976] [<ffffffff8146be53>] ? ret_from_intr+0x0/0xa
>> [ 1.248262] <EOI> [<ffffffff8102f277>] ? mwait_idle+0x57/0x80
>> [ 1.248796] [<ffffffff8102645c>] ? cpu_idle+0x5c/0xb0
>> [ 1.249080] ---[ end trace db7f668fb6fef4e1 ]---
>> 
>> Is this something Intel has to fix or is it a bug in the kernel?
>> 
>
> Here is a suggested fix:
>
> http://marc.info/?l=linux-kernel&m=126531123524059&w=2
>
> --
> Thomas
>

Hi,

This looks like what I want, will it be included in 2.6.33.1 or 2.6.34?

Justin.

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

* Re: 2.6.33: Problem continues: WARNING: at arch/x86/kernel/hpet.c:404 hpet_next_event+0x70/0x80
  2010-02-24 23:37 2.6.33: Problem continues: WARNING: at arch/x86/kernel/hpet.c:404 hpet_next_event+0x70/0x80 Justin Piszcz
  2010-02-25 14:03 ` Thomas Backlund
@ 2010-02-25 18:53 ` Pallipadi, Venkatesh
  2010-02-25 20:38   ` Thomas Gleixner
                     ` (2 more replies)
  1 sibling, 3 replies; 7+ messages in thread
From: Pallipadi, Venkatesh @ 2010-02-25 18:53 UTC (permalink / raw)
  To: Justin Piszcz; +Cc: linux-kernel, Thomas Gleixner

On Wed, Feb 24, 2010 at 03:37:04PM -0800, Justin Piszcz wrote:
> Hello,
> 
> Again, on the Intel DP55KG board:
> 
> # uname -a
> Linux host 2.6.33 #1 SMP Wed Feb 24 18:31:00 EST 2010 x86_64 GNU/Linux
> 
> [    1.237600] ------------[ cut here ]------------
> [    1.237890] WARNING: at arch/x86/kernel/hpet.c:404 hpet_next_event+0x70/0x80()
> [    1.238221] Hardware name:
> [    1.238504] hpet: compare register read back failed.
> [    1.238793] Modules linked in:
> [    1.239315] Pid: 0, comm: swapper Not tainted 2.6.33 #1
> [    1.239605] Call Trace:
> [    1.239886]  <IRQ>  [<ffffffff81056c13>] ? warn_slowpath_common+0x73/0xb0
> [    1.240409]  [<ffffffff81079608>] ? tick_dev_program_event+0x38/0xc0
> [    1.240699]  [<ffffffff81056cb0>] ? warn_slowpath_fmt+0x40/0x50
> [    1.240992]  [<ffffffff81079608>] ? tick_dev_program_event+0x38/0xc0
> [    1.241281]  [<ffffffff81041ad0>] ? hpet_next_event+0x70/0x80
> [    1.241573]  [<ffffffff81079608>] ? tick_dev_program_event+0x38/0xc0
> [    1.241859]  [<ffffffff81078e32>] ? tick_handle_oneshot_broadcast+0xe2/0x100
> [    1.246533]  [<ffffffff8102a67a>] ? timer_interrupt+0x1a/0x30
> [    1.246826]  [<ffffffff81085499>] ? handle_IRQ_event+0x39/0xd0
> [    1.247118]  [<ffffffff81087368>] ? handle_edge_irq+0xb8/0x160
> [    1.247407]  [<ffffffff81029f55>] ? handle_irq+0x15/0x20
> [    1.247689]  [<ffffffff810294a2>] ? do_IRQ+0x62/0xe0
> [    1.247976]  [<ffffffff8146be53>] ? ret_from_intr+0x0/0xa
> [    1.248262]  <EOI>  [<ffffffff8102f277>] ? mwait_idle+0x57/0x80
> [    1.248796]  [<ffffffff8102645c>] ? cpu_idle+0x5c/0xb0
> [    1.249080] ---[ end trace db7f668fb6fef4e1 ]---
> 
> Is this something Intel has to fix or is it a bug in the kernel?

This is a chipset erratum.

Thomas: You mentioned we can retain this check only for known-buggy and
hpet debug kind of options. But here is the simple workaround patch for
this particular erratum.

x86: Erratum workaround for read after write of HPET comparator

Some chipsets have a erratum due to which read immediately following a
write of HPET comparator returns old comparator value instead of most
recently written value.

Erratum 15 in
"Intel I/O Controller Hub 9 (ICH9) Family Specification Update"
(http://www.intel.com/assets/pdf/specupdate/316973.pdf)

Workaround for the errata is to read the comparator twice if the first
one fails.

Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
---
 arch/x86/kernel/hpet.c |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
index ad80a1c..7b0dd63 100644
--- a/arch/x86/kernel/hpet.c
+++ b/arch/x86/kernel/hpet.c
@@ -399,9 +399,15 @@ static int hpet_next_event(unsigned long delta,
 	 * then we might have a real hardware problem. We can not do
 	 * much about it here, but at least alert the user/admin with
 	 * a prominent warning.
+	 * An erratum on some chipsets (ICH9,..), results in comparator read
+	 * immediately following a write returning old value. Workaround
+	 * for this is to read this value second time, when first
+	 * read returns old value.
 	 */
-	WARN_ONCE(hpet_readl(HPET_Tn_CMP(timer)) != cnt,
+	if (unlikely((u32)hpet_readl(HPET_Tn_CMP(timer)) != cnt)) {
+		WARN_ONCE(hpet_readl(HPET_Tn_CMP(timer)) != cnt,
 		  KERN_WARNING "hpet: compare register read back failed.\n");
+	}
 
 	return (s32)(hpet_readl(HPET_COUNTER) - cnt) >= 0 ? -ETIME : 0;
 }
-- 
1.6.0.6


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

* Re: 2.6.33: Problem continues: WARNING: at arch/x86/kernel/hpet.c:404 hpet_next_event+0x70/0x80
  2010-02-25 18:53 ` Pallipadi, Venkatesh
@ 2010-02-25 20:38   ` Thomas Gleixner
  2010-04-01 22:58   ` [tip:x86/urgent] x86, hpet: Erratum workaround for read after write of HPET comparator tip-bot for Pallipadi, Venkatesh
  2010-04-29  1:36   ` [tip:x86/timers] x86, hpet: Restrict read back to affected ATI chipsets tip-bot for Thomas Gleixner
  2 siblings, 0 replies; 7+ messages in thread
From: Thomas Gleixner @ 2010-02-25 20:38 UTC (permalink / raw)
  To: Pallipadi, Venkatesh; +Cc: Justin Piszcz, linux-kernel

On Thu, 25 Feb 2010, Pallipadi, Venkatesh wrote:

> On Wed, Feb 24, 2010 at 03:37:04PM -0800, Justin Piszcz wrote:
> > Hello,
> > 
> > Again, on the Intel DP55KG board:
> > 
> > # uname -a
> > Linux host 2.6.33 #1 SMP Wed Feb 24 18:31:00 EST 2010 x86_64 GNU/Linux
> > 
> > [    1.237600] ------------[ cut here ]------------
> > [    1.237890] WARNING: at arch/x86/kernel/hpet.c:404 hpet_next_event+0x70/0x80()
> > [    1.238221] Hardware name:
> > [    1.238504] hpet: compare register read back failed.
> > [    1.238793] Modules linked in:
> > [    1.239315] Pid: 0, comm: swapper Not tainted 2.6.33 #1
> > [    1.239605] Call Trace:
> > [    1.239886]  <IRQ>  [<ffffffff81056c13>] ? warn_slowpath_common+0x73/0xb0
> > [    1.240409]  [<ffffffff81079608>] ? tick_dev_program_event+0x38/0xc0
> > [    1.240699]  [<ffffffff81056cb0>] ? warn_slowpath_fmt+0x40/0x50
> > [    1.240992]  [<ffffffff81079608>] ? tick_dev_program_event+0x38/0xc0
> > [    1.241281]  [<ffffffff81041ad0>] ? hpet_next_event+0x70/0x80
> > [    1.241573]  [<ffffffff81079608>] ? tick_dev_program_event+0x38/0xc0
> > [    1.241859]  [<ffffffff81078e32>] ? tick_handle_oneshot_broadcast+0xe2/0x100
> > [    1.246533]  [<ffffffff8102a67a>] ? timer_interrupt+0x1a/0x30
> > [    1.246826]  [<ffffffff81085499>] ? handle_IRQ_event+0x39/0xd0
> > [    1.247118]  [<ffffffff81087368>] ? handle_edge_irq+0xb8/0x160
> > [    1.247407]  [<ffffffff81029f55>] ? handle_irq+0x15/0x20
> > [    1.247689]  [<ffffffff810294a2>] ? do_IRQ+0x62/0xe0
> > [    1.247976]  [<ffffffff8146be53>] ? ret_from_intr+0x0/0xa
> > [    1.248262]  <EOI>  [<ffffffff8102f277>] ? mwait_idle+0x57/0x80
> > [    1.248796]  [<ffffffff8102645c>] ? cpu_idle+0x5c/0xb0
> > [    1.249080] ---[ end trace db7f668fb6fef4e1 ]---
> > 
> > Is this something Intel has to fix or is it a bug in the kernel?
> 
> This is a chipset erratum.
> 
> Thomas: You mentioned we can retain this check only for known-buggy and
> hpet debug kind of options. But here is the simple workaround patch for
> this particular erratum.

Yes, that'd be the preferred way. I need to find the box which had the
problem (ATI chipset) and force the readback for that one. That saves
all other machines the extra hardware access.

Thanks,

	tglx

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

* [tip:x86/urgent] x86, hpet: Erratum workaround for read after write of HPET comparator
  2010-02-25 18:53 ` Pallipadi, Venkatesh
  2010-02-25 20:38   ` Thomas Gleixner
@ 2010-04-01 22:58   ` tip-bot for Pallipadi, Venkatesh
  2010-04-29  1:36   ` [tip:x86/timers] x86, hpet: Restrict read back to affected ATI chipsets tip-bot for Thomas Gleixner
  2 siblings, 0 replies; 7+ messages in thread
From: tip-bot for Pallipadi, Venkatesh @ 2010-04-01 22:58 UTC (permalink / raw)
  To: linux-tip-commits
  Cc: linux-kernel, hpa, mingo, stable, venkatesh.pallipadi,
	venkatesh.pallipadi, tglx

Commit-ID:  8da854cb02156c90028233ae1e85ce46a1d3f82c
Gitweb:     http://git.kernel.org/tip/8da854cb02156c90028233ae1e85ce46a1d3f82c
Author:     Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com>
AuthorDate: Thu, 25 Feb 2010 10:53:48 -0800
Committer:  H. Peter Anvin <hpa@zytor.com>
CommitDate: Thu, 1 Apr 2010 15:21:47 -0700

x86, hpet: Erratum workaround for read after write of HPET comparator

On Wed, Feb 24, 2010 at 03:37:04PM -0800, Justin Piszcz wrote:
> Hello,
>
> Again, on the Intel DP55KG board:
>
> # uname -a
> Linux host 2.6.33 #1 SMP Wed Feb 24 18:31:00 EST 2010 x86_64 GNU/Linux
>
> [    1.237600] ------------[ cut here ]------------
> [    1.237890] WARNING: at arch/x86/kernel/hpet.c:404 hpet_next_event+0x70/0x80()
> [    1.238221] Hardware name:
> [    1.238504] hpet: compare register read back failed.
> [    1.238793] Modules linked in:
> [    1.239315] Pid: 0, comm: swapper Not tainted 2.6.33 #1
> [    1.239605] Call Trace:
> [    1.239886]  <IRQ>  [<ffffffff81056c13>] ? warn_slowpath_common+0x73/0xb0
> [    1.240409]  [<ffffffff81079608>] ? tick_dev_program_event+0x38/0xc0
> [    1.240699]  [<ffffffff81056cb0>] ? warn_slowpath_fmt+0x40/0x50
> [    1.240992]  [<ffffffff81079608>] ? tick_dev_program_event+0x38/0xc0
> [    1.241281]  [<ffffffff81041ad0>] ? hpet_next_event+0x70/0x80
> [    1.241573]  [<ffffffff81079608>] ? tick_dev_program_event+0x38/0xc0
> [    1.241859]  [<ffffffff81078e32>] ? tick_handle_oneshot_broadcast+0xe2/0x100
> [    1.246533]  [<ffffffff8102a67a>] ? timer_interrupt+0x1a/0x30
> [    1.246826]  [<ffffffff81085499>] ? handle_IRQ_event+0x39/0xd0
> [    1.247118]  [<ffffffff81087368>] ? handle_edge_irq+0xb8/0x160
> [    1.247407]  [<ffffffff81029f55>] ? handle_irq+0x15/0x20
> [    1.247689]  [<ffffffff810294a2>] ? do_IRQ+0x62/0xe0
> [    1.247976]  [<ffffffff8146be53>] ? ret_from_intr+0x0/0xa
> [    1.248262]  <EOI>  [<ffffffff8102f277>] ? mwait_idle+0x57/0x80
> [    1.248796]  [<ffffffff8102645c>] ? cpu_idle+0x5c/0xb0
> [    1.249080] ---[ end trace db7f668fb6fef4e1 ]---
>
> Is this something Intel has to fix or is it a bug in the kernel?

This is a chipset erratum.

Thomas: You mentioned we can retain this check only for known-buggy and
hpet debug kind of options. But here is the simple workaround patch for
this particular erratum.

Some chipsets have a erratum due to which read immediately following a
write of HPET comparator returns old comparator value instead of most
recently written value.

Erratum 15 in
"Intel I/O Controller Hub 9 (ICH9) Family Specification Update"
(http://www.intel.com/assets/pdf/specupdate/316973.pdf)

Workaround for the errata is to read the comparator twice if the first
one fails.

Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
LKML-Reference: <20100225185348.GA9674@linux-os.sc.intel.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Cc: Venkatesh Pallipadi <venkatesh.pallipadi@gmail.com>
Cc: <stable@kernel.org>
---
 arch/x86/kernel/hpet.c |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
index ee4fa1b..3d422da 100644
--- a/arch/x86/kernel/hpet.c
+++ b/arch/x86/kernel/hpet.c
@@ -399,9 +399,15 @@ static int hpet_next_event(unsigned long delta,
 	 * then we might have a real hardware problem. We can not do
 	 * much about it here, but at least alert the user/admin with
 	 * a prominent warning.
+	 * An erratum on some chipsets (ICH9,..), results in comparator read
+	 * immediately following a write returning old value. Workaround
+	 * for this is to read this value second time, when first
+	 * read returns old value.
 	 */
-	WARN_ONCE(hpet_readl(HPET_Tn_CMP(timer)) != cnt,
+	if (unlikely((u32)hpet_readl(HPET_Tn_CMP(timer)) != cnt)) {
+		WARN_ONCE(hpet_readl(HPET_Tn_CMP(timer)) != cnt,
 		  KERN_WARNING "hpet: compare register read back failed.\n");
+	}
 
 	return (s32)(hpet_readl(HPET_COUNTER) - cnt) >= 0 ? -ETIME : 0;
 }

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

* [tip:x86/timers] x86, hpet: Restrict read back to affected ATI chipsets
  2010-02-25 18:53 ` Pallipadi, Venkatesh
  2010-02-25 20:38   ` Thomas Gleixner
  2010-04-01 22:58   ` [tip:x86/urgent] x86, hpet: Erratum workaround for read after write of HPET comparator tip-bot for Pallipadi, Venkatesh
@ 2010-04-29  1:36   ` tip-bot for Thomas Gleixner
  2 siblings, 0 replies; 7+ messages in thread
From: tip-bot for Thomas Gleixner @ 2010-04-29  1:36 UTC (permalink / raw)
  To: linux-tip-commits; +Cc: linux-kernel, hpa, mingo, tglx, venki

Commit-ID:  30a564be9d9554c168a654eddc2165869cc0d7bf
Gitweb:     http://git.kernel.org/tip/30a564be9d9554c168a654eddc2165869cc0d7bf
Author:     Thomas Gleixner <tglx@linutronix.de>
AuthorDate: Tue, 13 Apr 2010 15:31:36 +0200
Committer:  H. Peter Anvin <hpa@zytor.com>
CommitDate: Wed, 28 Apr 2010 18:14:29 -0700

x86, hpet: Restrict read back to affected ATI chipsets

After programming the HPET, we do a readback as a workaround for
ATI/SBx00 chipsets as a synchronization.  Unfortunately this triggers
an erratum in newer ICH chipsets (ICH9+) where reading the comparator
immediately after the write returns the old value.  Furthermore, as
always, I/O reads are bad for performance.

Therefore, restrict the readback to the chipsets that need it, or, for
debugging purposes, when we are running with hpet=verbose.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Venkatesh Pallipadi <venki@google.com>
LKML-Reference: <20100225185348.GA9674@linux-os.sc.intel.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
---
 arch/x86/include/asm/hpet.h |    1 +
 arch/x86/kernel/hpet.c      |   29 +++++++++++++++++------------
 arch/x86/kernel/quirks.c    |    5 +++++
 3 files changed, 23 insertions(+), 12 deletions(-)

diff --git a/arch/x86/include/asm/hpet.h b/arch/x86/include/asm/hpet.h
index 1d5c08a..004e6e2 100644
--- a/arch/x86/include/asm/hpet.h
+++ b/arch/x86/include/asm/hpet.h
@@ -68,6 +68,7 @@ extern unsigned long force_hpet_address;
 extern u8 hpet_blockid;
 extern int hpet_force_user;
 extern u8 hpet_msi_disable;
+extern u8 hpet_readback_cmp;
 extern int is_hpet_enabled(void);
 extern int hpet_enable(void);
 extern void hpet_disable(void);
diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
index 23b4ecd..a198b7c 100644
--- a/arch/x86/kernel/hpet.c
+++ b/arch/x86/kernel/hpet.c
@@ -36,6 +36,7 @@
 unsigned long				hpet_address;
 u8					hpet_blockid; /* OS timer block num */
 u8					hpet_msi_disable;
+u8					hpet_readback_cmp;
 
 #ifdef CONFIG_PCI_MSI
 static unsigned long			hpet_num_timers;
@@ -395,19 +396,23 @@ static int hpet_next_event(unsigned long delta,
 	 * at that point and we would wait for the next hpet interrupt
 	 * forever. We found out that reading the CMP register back
 	 * forces the transfer so we can rely on the comparison with
-	 * the counter register below. If the read back from the
-	 * compare register does not match the value we programmed
-	 * then we might have a real hardware problem. We can not do
-	 * much about it here, but at least alert the user/admin with
-	 * a prominent warning.
-	 * An erratum on some chipsets (ICH9,..), results in comparator read
-	 * immediately following a write returning old value. Workaround
-	 * for this is to read this value second time, when first
-	 * read returns old value.
+	 * the counter register below.
+	 *
+	 * That works fine on those ATI chipsets, but on newer Intel
+	 * chipsets (ICH9...) this triggers due to an erratum: Reading
+	 * the comparator immediately following a write is returning
+	 * the old value.
+	 *
+	 * We restrict the read back to the affected ATI chipsets (set
+	 * by quirks) and also run it with hpet=verbose for debugging
+	 * purposes.
 	 */
-	if (unlikely((u32)hpet_readl(HPET_Tn_CMP(timer)) != cnt)) {
-		WARN_ONCE(hpet_readl(HPET_Tn_CMP(timer)) != cnt,
-		  KERN_WARNING "hpet: compare register read back failed.\n");
+	if (hpet_readback_cmp || hpet_verbose) {
+		u32 cmp = hpet_readl(HPET_Tn_CMP(timer));
+
+		if (cmp != cnt)
+			printk_once(KERN_WARNING
+			    "hpet: compare register read back failed.\n");
 	}
 
 	return (s32)(hpet_readl(HPET_COUNTER) - cnt) >= 0 ? -ETIME : 0;
diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c
index 12e9fea..cd2c336 100644
--- a/arch/x86/kernel/quirks.c
+++ b/arch/x86/kernel/quirks.c
@@ -495,10 +495,15 @@ void force_hpet_resume(void)
 /*
  * HPET MSI on some boards (ATI SB700/SB800) has side effect on
  * floppy DMA. Disable HPET MSI on such platforms.
+ *
+ * Also force the read back of the CMP register in hpet_next_event()
+ * to work around the problem that the CMP register write seems to be
+ * delayed. See hpet_next_event() for details.
  */
 static void force_disable_hpet_msi(struct pci_dev *unused)
 {
 	hpet_msi_disable = 1;
+	hpet_readback_cmp = 1;
 }
 
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_SBX00_SMBUS,

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

end of thread, other threads:[~2010-04-29  1:37 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-02-24 23:37 2.6.33: Problem continues: WARNING: at arch/x86/kernel/hpet.c:404 hpet_next_event+0x70/0x80 Justin Piszcz
2010-02-25 14:03 ` Thomas Backlund
2010-02-25 14:22   ` Justin Piszcz
2010-02-25 18:53 ` Pallipadi, Venkatesh
2010-02-25 20:38   ` Thomas Gleixner
2010-04-01 22:58   ` [tip:x86/urgent] x86, hpet: Erratum workaround for read after write of HPET comparator tip-bot for Pallipadi, Venkatesh
2010-04-29  1:36   ` [tip:x86/timers] x86, hpet: Restrict read back to affected ATI chipsets tip-bot for Thomas Gleixner

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.