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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox