From: Andrew Morton <akpm@linux-foundation.org>
To: john stultz <johnstul@us.ibm.com>
Cc: "Guilherme M. Schroeder" <guilherme@centralinf.com.br>,
lkml <linux-kernel@vger.kernel.org>, Andi Kleen <ak@suse.de>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] Blacklist Dell Optiplex 320 from using the HPET
Date: Fri, 4 May 2007 14:44:08 -0700 [thread overview]
Message-ID: <20070504144408.c041d8df.akpm@linux-foundation.org> (raw)
In-Reply-To: <1178314144.6094.7.camel@localhost.localdomain>
On Fri, 04 May 2007 14:29:04 -0700
john stultz <johnstul@us.ibm.com> wrote:
> One of the 2.6.21 regressions was Guilherme's problem seeing his box
> lock up when the system detected an unstable TSC and dropped back to
> using the HPET.
>
> In digging deeper, we found the HPET is not actually incrementing on
> this system. And in fact, the reason why this issue just cropped up was
> because of Thomas's clocksource watchdog code was comparing the TSC to
> the HPET (which wasn't moving) and thought the TSC was broken.
>
> Anyway, Guliherme checked for a BIOS update and did not find one, so
> I've added a DMI blacklist against his system so the HPET is not used.
>
> Many thanks to Guilherme for the slow and laborious testing that finally
> narrowed down this issue.
>
OK, I tagged that for -stable too.
>
> diff --git a/arch/i386/kernel/hpet.c b/arch/i386/kernel/hpet.c
> index 17d7345..1ae27f3 100644
> --- a/arch/i386/kernel/hpet.c
> +++ b/arch/i386/kernel/hpet.c
> @@ -5,6 +5,7 @@
> #include <linux/init.h>
> #include <linux/sysdev.h>
> #include <linux/pm.h>
> +#include <linux/dmi.h>
>
> #include <asm/hpet.h>
> #include <asm/io.h>
> @@ -48,6 +49,31 @@ static int __init hpet_setup(char* str)
> }
> __setup("hpet=", hpet_setup);
>
> +
> +/* DMI Blacklist for bad HPETs */
> +static int __init dmi_mark_hpet_broken(struct dmi_system_id *d)
> +{
> + printk(KERN_NOTICE "%s detected: HPET does not function.\n",
> + d->ident);
> + boot_hpet_disable = 1;
> + return 0;
> +}
> +
> +/* List of systems that have known HPETproblems */
> +static struct dmi_system_id bad_hpet_dmi_table[] = {
> + {
> + .callback = dmi_mark_hpet_broken,
> + .ident = "Dell OptiPlex 320",
> + .matches = {
> + DMI_MATCH(DMI_PRODUCT_NAME, "OptiPlex 320"),
> + DMI_MATCH(DMI_BOARD_VENDOR, "Dell Inc."),
> + DMI_MATCH(DMI_BOARD_NAME, "0UT237"),
> + },
> + },
> + {}
> +};
> +
> +
> static inline int is_hpet_capable(void)
> {
> return (!boot_hpet_disable && hpet_address);
> @@ -228,6 +254,8 @@ int __init hpet_enable(void)
> uint64_t hpet_freq;
> u64 tmp;
>
> + dmi_check_system(bad_hpet_dmi_table);
> +
> if (!is_hpet_capable())
> return 0;
The table can be __initdata, can't it?
--- a/arch/i386/kernel/hpet.c~blacklist-dell-optiplex-320-from-using-the-hpet-fix
+++ a/arch/i386/kernel/hpet.c
@@ -60,7 +60,7 @@ static int __init dmi_mark_hpet_broken(s
}
/* List of systems that have known HPETproblems */
-static struct dmi_system_id bad_hpet_dmi_table[] = {
+static struct dmi_system_id __initdata bad_hpet_dmi_table[] = {
{
.callback = dmi_mark_hpet_broken,
.ident = "Dell OptiPlex 320",
@@ -73,7 +73,6 @@ static struct dmi_system_id bad_hpet_dmi
{}
};
-
static inline int is_hpet_capable(void)
{
return (!boot_hpet_disable && hpet_address);
_
next prev parent reply other threads:[~2007-05-04 21:44 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-04 21:29 [PATCH] Blacklist Dell Optiplex 320 from using the HPET john stultz
2007-05-04 21:44 ` Andrew Morton [this message]
2007-05-04 21:47 ` john stultz
2007-05-04 23:19 ` Andi Kleen
2007-05-04 23:18 ` Andi Kleen
2007-05-04 23:27 ` john stultz
2007-05-05 14:26 ` Thomas Gleixner
2007-05-05 14:30 ` Thomas Gleixner
2007-05-05 15:58 ` Henrique de Moraes Holschuh
2007-05-07 18:59 ` Andreas Mohr
2007-05-07 20:41 ` Henrique de Moraes Holschuh
2007-05-05 17:24 ` Andi Kleen
2007-05-05 19:15 ` Thomas Gleixner
2007-05-05 22:05 ` Andi Kleen
2007-05-05 22:41 ` Guilherme M. Schroeder
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=20070504144408.c041d8df.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=ak@suse.de \
--cc=guilherme@centralinf.com.br \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--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.