From: Borislav Petkov <bp@amd64.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Markus Trippelsdorf <markus@trippelsdorf.de>,
Borislav Petkov <bp@amd64.org>, Borislav Petkov <bp@alien8.de>,
john stultz <johnstul@us.ibm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"hpa@linux.intel.com" <hpa@linux.intel.com>,
Ingo Molnar <mingo@elte.hu>,
"Herrmann3, Andreas" <Andreas.Herrmann3@amd.com>,
"heiko.carstens@de.ibm.com" <heiko.carstens@de.ibm.com>,
"a.p.zijlstra@chello.nl" <a.p.zijlstra@chello.nl>,
"avi@redhat.com" <avi@redhat.com>,
"mtosatti@redhat.com" <mtosatti@redhat.com>
Subject: Re: [bisected] Clocksource tsc unstable git
Date: Fri, 5 Nov 2010 17:09:19 +0100 [thread overview]
Message-ID: <20101105160919.GC25704@aftab> (raw)
In-Reply-To: <alpine.LFD.2.00.1011021626160.9357@localhost6.localdomain6>
On Tue, Nov 02, 2010 at 11:26:54AM -0400, Thomas Gleixner wrote:
> Ok, I'm waiting for Boris to get us the confirmation from HW folks.
Ok, I don't have much but it could be something. We could use the
minimum tick u16 value in the ACPI HPET table, offset 53:
Main Counter Minimum 2 53 Unit: Clock tick
Clock_tick in Periodic The minimum clock ticks can be set without lost
Mode interrupts while the counter is programmed to operate in
*Note#3 periodic mode
...
* Note #3: This field is written by BIOS and may be chipset and/or
platform dependent. This indicates the minimum value that must be used
for any counter programmed in periodic mode to avoid lost interrupts.
For any counter x that has been configured for periodic mode, the number
can be programmed in any Tx_Compare Register must be greater than P,
where P = (Minimum Period) / (Main counter period) in order to avoid
lost interrupts.
However, we don't know (yet) whether this can be used in the
non-periodic mode too. My gut feeling says yes but I wouldn't trust it.
We went and collected that value a bunch of systems and it looks like it
would need more massaging (read: capping) since some BIOSen simply write
crap in it. It ranges from
- 0x37ee on old nVidia and Intel boards (this is definitely crap, I
can't imagine a minimum ticks value of 14318 for a HPET but who knows)
- 0x1000 on a HP machine (also fishy)
- 0x10, 0x14 on current SBxxx boards
- 0x80 on newer Intel boards
and it looks like 0x80 is also the default value which we can use as a
capping value. Btw, I've been running the following on the machine in
question for a while now and no lockups so far.
Opinions?
---
arch/x86/include/asm/hpet.h | 1 +
arch/x86/kernel/acpi/boot.c | 12 +++++++++---
arch/x86/kernel/hpet.c | 3 ++-
3 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/hpet.h b/arch/x86/include/asm/hpet.h
index 2c392d6..01d9480 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 u16 hpet_min_tick;
extern int is_hpet_enabled(void);
extern int hpet_enable(void);
extern void hpet_disable(void);
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 71232b9..37b93e8 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -772,9 +772,6 @@ static int __init acpi_parse_hpet(struct acpi_table_header *table)
hpet_address >>= 32;
}
#endif
- printk(KERN_INFO PREFIX "HPET id: %#x base: %#lx\n",
- hpet_tbl->id, hpet_address);
-
/*
* Allocate and initialize the HPET firmware resource for adding into
* the resource tree during the lateinit timeframe.
@@ -790,6 +787,15 @@ static int __init acpi_parse_hpet(struct acpi_table_header *table)
hpet_res->start = hpet_address;
hpet_res->end = hpet_address + (1 * 1024) - 1;
+ hpet_min_tick = hpet_tbl->minimum_tick;
+ if (hpet_min_tick > 0x80) {
+ printk(KERN_WARNING PREFIX "Limiting HPET read delay to 0x80.\n");
+ hpet_min_tick = 0x80;
+ }
+
+ printk(KERN_INFO PREFIX "HPET id: %#x base: %#lx min tick: %d\n",
+ hpet_tbl->id, hpet_address, hpet_min_tick);
+
return 0;
}
diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
index e49c3b9..a0b790a 100644
--- a/arch/x86/kernel/hpet.c
+++ b/arch/x86/kernel/hpet.c
@@ -40,6 +40,7 @@ u8 hpet_msi_disable;
static unsigned long hpet_num_timers;
#endif
static void __iomem *hpet_virt_address;
+u16 hpet_min_tick = 0x80;
struct hpet_dev {
struct clock_event_device evt;
@@ -408,7 +409,7 @@ static int hpet_next_event(unsigned long delta,
*/
res = (s32)(cnt - hpet_readl(HPET_COUNTER));
- return res < 8 ? -ETIME : 0;
+ return res < hpet_min_tick ? -ETIME : 0;
}
static void hpet_legacy_set_mode(enum clock_event_mode mode,
--
1.7.3.1.50.g1e633
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632
next prev parent reply other threads:[~2010-11-05 16:11 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-26 11:20 Clocksource tsc unstable (delta = -8589361717 ns) in current git Markus Trippelsdorf
2010-10-26 13:18 ` Borislav Petkov
2010-10-26 13:58 ` Markus Trippelsdorf
2010-10-26 14:05 ` Markus Trippelsdorf
2010-10-26 14:38 ` Peter Zijlstra
2010-10-26 15:46 ` Thomas Gleixner
2010-10-26 16:41 ` Borislav Petkov
2010-10-26 15:48 ` Thomas Gleixner
2010-10-26 17:56 ` Markus Trippelsdorf
2010-10-26 18:19 ` Borislav Petkov
2010-10-26 19:18 ` john stultz
2010-10-27 14:26 ` Markus Trippelsdorf
2010-10-27 18:26 ` [bisected] Clocksource tsc unstable git markus
2010-10-27 19:36 ` Peter Zijlstra
2010-10-27 19:42 ` Markus Trippelsdorf
2010-10-27 19:58 ` Marcelo Tosatti
2010-11-09 12:58 ` Heiko Carstens
2010-11-09 13:07 ` Markus Trippelsdorf
2010-11-09 13:21 ` Markus Trippelsdorf
2010-11-09 13:28 ` Heiko Carstens
2010-11-09 13:45 ` Peter Zijlstra
2010-11-09 13:33 ` Peter Zijlstra
2010-10-29 8:18 ` Borislav Petkov
2010-10-29 8:30 ` Markus Trippelsdorf
2010-10-29 10:27 ` Borislav Petkov
2010-10-29 11:34 ` Markus Trippelsdorf
2010-10-29 11:39 ` Borislav Petkov
2010-10-29 11:54 ` Markus Trippelsdorf
2010-10-29 13:13 ` Borislav Petkov
2010-10-29 12:14 ` Thomas Gleixner
2010-10-29 17:00 ` Borislav Petkov
2010-10-29 17:26 ` Markus Trippelsdorf
2010-11-01 18:05 ` Thomas Gleixner
2010-11-01 18:45 ` Markus Trippelsdorf
2010-11-02 15:26 ` Thomas Gleixner
2010-11-05 16:09 ` Borislav Petkov [this message]
2010-11-05 16:42 ` Markus Trippelsdorf
2010-11-05 17:45 ` Markus Trippelsdorf
2010-11-05 21:27 ` Markus Trippelsdorf
2010-11-05 21:32 ` Borislav Petkov
2010-11-09 14:02 ` Thomas Gleixner
2010-11-09 14:39 ` Borislav Petkov
2010-11-17 23:21 ` Markus Trippelsdorf
2010-11-24 11:25 ` Borislav Petkov
2010-10-29 17:34 ` Thomas Gleixner
2010-10-27 3:24 ` Clocksource tsc unstable (delta = -8589361717 ns) in current git Mike Galbraith
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101105160919.GC25704@aftab \
--to=bp@amd64.org \
--cc=Andreas.Herrmann3@amd.com \
--cc=a.p.zijlstra@chello.nl \
--cc=avi@redhat.com \
--cc=bp@alien8.de \
--cc=heiko.carstens@de.ibm.com \
--cc=hpa@linux.intel.com \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=markus@trippelsdorf.de \
--cc=mingo@elte.hu \
--cc=mtosatti@redhat.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.