-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Thomas Gleixner <[email protected]>
Some systems have a HPET which is not incrementing, which leads to a
complete hang. Detect it during HPET setup.
Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
---
[chrisw: Why is this not upstream yet?]
---
arch/i386/kernel/hpet.c | 24 +++++++++++++++++++++++-
1 file changed, 23 insertions(+), 1 deletion(-)
--- linux-2.6.21.1.orig/arch/i386/kernel/hpet.c
+++ linux-2.6.21.1/arch/i386/kernel/hpet.c
@@ -226,7 +226,8 @@ int __init hpet_enable(void)
{
unsigned long id;
uint64_t hpet_freq;
- u64 tmp;
+ u64 tmp, start, now;
+ cycle_t t1;
if (!is_hpet_capable())
return 0;
@@ -273,6 +274,27 @@ int __init hpet_enable(void)
/* Start the counter */
hpet_start_counter();
+ /* Verify whether hpet counter works */
+ t1 = read_hpet();
+ rdtscll(start);
+
+ /*
+ * We don't know the TSC frequency yet, but waiting for
+ * 200000 TSC cycles is safe:
+ * 4 GHz == 50us
+ * 1 GHz == 200us
+ */
+ do {
+ rep_nop();
+ rdtscll(now);
+ } while ((now - start) < 200000UL);
+
+ if (t1 == read_hpet()) {
+ printk(KERN_WARNING
+ "HPET counter not counting. HPET disabled\n");
+ goto out_nohpet;
+ }
+
/* Initialize and register HPET clocksource
*
* hpet period is in femto seconds per cycle
--
On Mon, 2007-05-21 at 12:16 -0700, Chris Wright wrote:
> plain text document attachment
> (i386-hpet-check-if-the-counter-works.patch)
> -stable review patch. If anyone has any objections, please let us know.
> ---------------------
>
> From: Thomas Gleixner <[email protected]>
>
> Some systems have a HPET which is not incrementing, which leads to a
> complete hang. Detect it during HPET setup.
>
> Signed-off-by: Thomas Gleixner <[email protected]>
> Signed-off-by: Chris Wright <[email protected]>
> ---
> [chrisw: Why is this not upstream yet?]
Dunno. There is another one missing:
------------------------------->
Subject: NOHZ: Rate limit the local softirq pending warning output
The warning in the NOHZ code, which triggers when a CPU goes idle with
softirqs pending can fill up the logs quite quickly. Rate limit the
output until we found the root cause of that problem.
Signed-off-by: Thomas Gleixner <[email protected]>
Index: linux-2.6.21/kernel/time/tick-sched.c
===================================================================
--- linux-2.6.21.orig/kernel/time/tick-sched.c
+++ linux-2.6.21/kernel/time/tick-sched.c
@@ -167,9 +167,15 @@ void tick_nohz_stop_sched_tick(void)
goto end;
cpu = smp_processor_id();
- if (unlikely(local_softirq_pending()))
- printk(KERN_ERR "NOHZ: local_softirq_pending %02x\n",
- local_softirq_pending());
+ if (unlikely(local_softirq_pending())) {
+ static int ratelimit;
+
+ if (ratelimit < 10) {
+ printk(KERN_ERR "NOHZ: local_softirq_pending %02x\n",
+ local_softirq_pending());
+ ratelimit++;
+ }
+ }
now = ktime_get();
/*
On Mon, 2007-05-21 at 21:58 +0200, Thomas Gleixner wrote:
> Dunno. There is another one missing:
What happened to the maxcpus=1 hard lock prevention patch ?
tglx
On Mon, 2007-05-21 at 13:33 -0700, Chris Wright wrote:
> * Thomas Gleixner ([email protected]) wrote:
> > What happened to the maxcpus=1 hard lock prevention patch ?
>
> i placed it in the queue for .3. (primarily due to timing and since it
> hadn't hit upstream yet).
Fair enough.
tglx
* Thomas Gleixner ([email protected]) wrote:
> What happened to the maxcpus=1 hard lock prevention patch ?
i placed it in the queue for .3. (primarily due to timing and since it
hadn't hit upstream yet).
On Mon, 21 May 2007 21:58:55 +0200
Thomas Gleixner <[email protected]> wrote:
> The warning in the NOHZ code, which triggers when a CPU goes idle with
> softirqs pending can fill up the logs quite quickly. Rate limit the
> output until we found the root cause of that problem.
>
> Signed-off-by: Thomas Gleixner <[email protected]>
>
> Index: linux-2.6.21/kernel/time/tick-sched.c
> ===================================================================
> --- linux-2.6.21.orig/kernel/time/tick-sched.c
> +++ linux-2.6.21/kernel/time/tick-sched.c
> @@ -167,9 +167,15 @@ void tick_nohz_stop_sched_tick(void)
> goto end;
>
> cpu = smp_processor_id();
> - if (unlikely(local_softirq_pending()))
> - printk(KERN_ERR "NOHZ: local_softirq_pending %02x\n",
> - local_softirq_pending());
> + if (unlikely(local_softirq_pending())) {
> + static int ratelimit;
> +
> + if (ratelimit < 10) {
> + printk(KERN_ERR "NOHZ: local_softirq_pending %02x\n",
> + local_softirq_pending());
> + ratelimit++;
> + }
> + }
that's not a "rate" limit. I resist the temptation to rename it to "limit"
to keep mainline and -stable in sync, and coz it's temporary (we hope).
On Mon, 2007-05-21 at 14:57 -0700, Andrew Morton wrote:
> On Mon, 21 May 2007 21:58:55 +0200
> Thomas Gleixner <[email protected]> wrote:
>
> > The warning in the NOHZ code, which triggers when a CPU goes idle with
> > softirqs pending can fill up the logs quite quickly. Rate limit the
> > output until we found the root cause of that problem.
> >
> > Signed-off-by: Thomas Gleixner <[email protected]>
> >
> > Index: linux-2.6.21/kernel/time/tick-sched.c
> > ===================================================================
> > --- linux-2.6.21.orig/kernel/time/tick-sched.c
> > +++ linux-2.6.21/kernel/time/tick-sched.c
> > @@ -167,9 +167,15 @@ void tick_nohz_stop_sched_tick(void)
> > goto end;
> >
> > cpu = smp_processor_id();
> > - if (unlikely(local_softirq_pending()))
> > - printk(KERN_ERR "NOHZ: local_softirq_pending %02x\n",
> > - local_softirq_pending());
> > + if (unlikely(local_softirq_pending())) {
> > + static int ratelimit;
> > +
> > + if (ratelimit < 10) {
> > + printk(KERN_ERR "NOHZ: local_softirq_pending %02x\n",
> > + local_softirq_pending());
> > + ratelimit++;
> > + }
> > + }
>
> that's not a "rate" limit. I resist the temptation to rename it to "limit"
> to keep mainline and -stable in sync, and coz it's temporary (we hope).
Point taken.
tglx
the HPET specification allows for HPETs with *much* lower resolution than
50us. in fact Fmin is 10Hz iirc. (sorry to jump in so late, but i'm
about a month behind on the list.)
-dean
On Mon, 21 May 2007, Chris Wright wrote:
> -stable review patch. If anyone has any objections, please let us know.
> ---------------------
>
> From: Thomas Gleixner <[email protected]>
>
> Some systems have a HPET which is not incrementing, which leads to a
> complete hang. Detect it during HPET setup.
>
> Signed-off-by: Thomas Gleixner <[email protected]>
> Signed-off-by: Chris Wright <[email protected]>
> ---
> [chrisw: Why is this not upstream yet?]
>
> ---
> arch/i386/kernel/hpet.c | 24 +++++++++++++++++++++++-
> 1 file changed, 23 insertions(+), 1 deletion(-)
>
> --- linux-2.6.21.1.orig/arch/i386/kernel/hpet.c
> +++ linux-2.6.21.1/arch/i386/kernel/hpet.c
> @@ -226,7 +226,8 @@ int __init hpet_enable(void)
> {
> unsigned long id;
> uint64_t hpet_freq;
> - u64 tmp;
> + u64 tmp, start, now;
> + cycle_t t1;
>
> if (!is_hpet_capable())
> return 0;
> @@ -273,6 +274,27 @@ int __init hpet_enable(void)
> /* Start the counter */
> hpet_start_counter();
>
> + /* Verify whether hpet counter works */
> + t1 = read_hpet();
> + rdtscll(start);
> +
> + /*
> + * We don't know the TSC frequency yet, but waiting for
> + * 200000 TSC cycles is safe:
> + * 4 GHz == 50us
> + * 1 GHz == 200us
> + */
> + do {
> + rep_nop();
> + rdtscll(now);
> + } while ((now - start) < 200000UL);
> +
> + if (t1 == read_hpet()) {
> + printk(KERN_WARNING
> + "HPET counter not counting. HPET disabled\n");
> + goto out_nohpet;
> + }
> +
> /* Initialize and register HPET clocksource
> *
> * hpet period is in femto seconds per cycle
>
> --
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
ugh... do not send email before breakfast. do not send email before
breakfast. nevermind :)
-dean
On Tue, 5 Jun 2007, dean gaudet wrote:
> the HPET specification allows for HPETs with *much* lower resolution than
> 50us. in fact Fmin is 10Hz iirc. (sorry to jump in so late, but i'm
> about a month behind on the list.)
>
> -dean
>
> On Mon, 21 May 2007, Chris Wright wrote:
>
> > -stable review patch. If anyone has any objections, please let us know.
> > ---------------------
> >
> > From: Thomas Gleixner <[email protected]>
> >
> > Some systems have a HPET which is not incrementing, which leads to a
> > complete hang. Detect it during HPET setup.
> >
> > Signed-off-by: Thomas Gleixner <[email protected]>
> > Signed-off-by: Chris Wright <[email protected]>
> > ---
> > [chrisw: Why is this not upstream yet?]
> >
> > ---
> > arch/i386/kernel/hpet.c | 24 +++++++++++++++++++++++-
> > 1 file changed, 23 insertions(+), 1 deletion(-)
> >
> > --- linux-2.6.21.1.orig/arch/i386/kernel/hpet.c
> > +++ linux-2.6.21.1/arch/i386/kernel/hpet.c
> > @@ -226,7 +226,8 @@ int __init hpet_enable(void)
> > {
> > unsigned long id;
> > uint64_t hpet_freq;
> > - u64 tmp;
> > + u64 tmp, start, now;
> > + cycle_t t1;
> >
> > if (!is_hpet_capable())
> > return 0;
> > @@ -273,6 +274,27 @@ int __init hpet_enable(void)
> > /* Start the counter */
> > hpet_start_counter();
> >
> > + /* Verify whether hpet counter works */
> > + t1 = read_hpet();
> > + rdtscll(start);
> > +
> > + /*
> > + * We don't know the TSC frequency yet, but waiting for
> > + * 200000 TSC cycles is safe:
> > + * 4 GHz == 50us
> > + * 1 GHz == 200us
> > + */
> > + do {
> > + rep_nop();
> > + rdtscll(now);
> > + } while ((now - start) < 200000UL);
> > +
> > + if (t1 == read_hpet()) {
> > + printk(KERN_WARNING
> > + "HPET counter not counting. HPET disabled\n");
> > + goto out_nohpet;
> > + }
> > +
> > /* Initialize and register HPET clocksource
> > *
> > * hpet period is in femto seconds per cycle
> >
> > --
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Tue, 5 Jun 2007, dean gaudet wrote:
>
> the HPET specification allows for HPETs with *much* lower resolution than
> 50us. in fact Fmin is 10Hz iirc. (sorry to jump in so late, but i'm
> about a month behind on the list.)
Well, for such a broken HPET, the right thing to do is to just not use it,
so who cares? It might as well be considered non-incrementing at all.
Linus