en; David Bahi; LKML;
> >[EMAIL PROTECTED]; Andrew Morton; Ingo Molnar;
> >Gregory Haskins
> >Subject: Re: nmi_watchdog fix for x86_64 to be more like i386
> >
> >>
> >> The only workaround for chipsets ignoring IRQ affinity would
> >be to keep
> >
regory Haskins
>Subject: Re: nmi_watchdog fix for x86_64 to be more like i386
>
>>
>> The only workaround for chipsets ignoring IRQ affinity would
>be to keep
>> track on which CPU irq 0 happens and then restart APIC timer
>interrupts
>> on the others (or send IPIs)
> Hummm, a directory appears to be protected, or DNE. I get "failed to
> change directory".
Sorry typo
ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/patches/fix-watchdog
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
On Fri, 2007-10-05 at 18:03 +0200, Andi Kleen wrote:
> > If it's agreed that this is the fix - can you submit a proper [PATCH] so
> > all users of watchdog_use_timer_and_hpet_on_x86_64.patch can be removed,
> > and replaced with yours.
>
>
> If it's agreed that this is the fix - can you submit a proper [PATCH] so
> all users of watchdog_use_timer_and_hpet_on_x86_64.patch can be removed,
> and replaced with yours.
ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/patches/watchdog-fix
-Andi
-
To unsubscribe from this list: send the
On Mon, 2007-10-01 at 23:41 +0200, Andi Kleen wrote:
> > IRQ_NOBALANCING is not preventing cpu unplug. It moves the affinity to the
> > next CPU, but the check in NMI watchdog for CPU == 0 would not longer
> > work.
>
> That cannot happen right now because cpu_disable() on both i386/x86-64
>
If it's agreed that this is the fix - can you submit a proper [PATCH] so
all users of watchdog_use_timer_and_hpet_on_x86_64.patch can be removed,
and replaced with yours.
ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/patches/watchdog-fix
-Andi
-
To unsubscribe from this list: send the line
On Mon, 2007-10-01 at 23:41 +0200, Andi Kleen wrote:
IRQ_NOBALANCING is not preventing cpu unplug. It moves the affinity to the
next CPU, but the check in NMI watchdog for CPU == 0 would not longer
work.
That cannot happen right now because cpu_disable() on both i386/x86-64
reject CPU
On Fri, 2007-10-05 at 18:03 +0200, Andi Kleen wrote:
If it's agreed that this is the fix - can you submit a proper [PATCH] so
all users of watchdog_use_timer_and_hpet_on_x86_64.patch can be removed,
and replaced with yours.
ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/patches/watchdog-fix
Hummm, a directory appears to be protected, or DNE. I get failed to
change directory.
Sorry typo
ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/patches/fix-watchdog
-Andi
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
fix for x86_64 to be more like i386
The only workaround for chipsets ignoring IRQ affinity would
be to keep
track on which CPU irq 0 happens and then restart APIC timer
interrupts
on the others (or send IPIs) as needed. But that would be
fairly ugly.
The clock events code does handle
Molnar;
Gregory Haskins
Subject: Re: nmi_watchdog fix for x86_64 to be more like i386
The only workaround for chipsets ignoring IRQ affinity would
be to keep
track on which CPU irq 0 happens and then restart APIC timer
interrupts
on the others (or send IPIs) as needed
On Tue, 2 Oct 2007, Andi Kleen wrote:
> > Agreed.
> >
> > I just got a x8664-hrt report, where I found the following oddity:
> >
> > 0: 1197 172881 IO-APIC-edge timer
> >
> > That's one of those infamous AMD C1E boxen. Strange, all my systems have
> > IRQ#0 on CPU#0 and
On Tue, 2 Oct 2007, Andi Kleen wrote:
Agreed.
I just got a x8664-hrt report, where I found the following oddity:
0: 1197 172881 IO-APIC-edge timer
That's one of those infamous AMD C1E boxen. Strange, all my systems have
IRQ#0 on CPU#0 and nowhere else. Any
> Agreed.
>
> I just got a x8664-hrt report, where I found the following oddity:
>
> 0: 1197 172881 IO-APIC-edge timer
>
> That's one of those infamous AMD C1E boxen. Strange, all my systems have
> IRQ#0 on CPU#0 and nowhere else. Any idea ?
Hmm, in lowestpriority mode it
On Tue, 02 Oct 2007 07:56:24 +0300
Mika Penttilä <[EMAIL PROTECTED]> wrote:
> Here I have with stock FC7 (2.6.22.9-91) kernel :
> 0: 107835 133459760 IO-APIC-edge timer
>
fwiw this is entirely done by the hardware; no irq balancer has touched
this one (fc7 has the new irqbalancer
Thomas Gleixner wrote:
On Tue, 2 Oct 2007, Andi Kleen wrote:
OTOH, the accounting hook would allow us to remove the IRQ#0 -> CPU#0
restriction. Not sure whether it's worth the trouble.
Some SIS chipsets hang the machine when you migrate irq 0 to another
CPU. It's better to keep that
On Tue, 2 Oct 2007 00:47:12 +0200 (CEST)
Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> On Tue, 2 Oct 2007, Andi Kleen wrote:
> >
> > > OTOH, the accounting hook would allow us to remove the IRQ#0 ->
> > > CPU#0 restriction. Not sure whether it's worth the trouble.
> >
> > Some SIS chipsets hang
On Tue, 2 Oct 2007, Andi Kleen wrote:
>
> > OTOH, the accounting hook would allow us to remove the IRQ#0 -> CPU#0
> > restriction. Not sure whether it's worth the trouble.
>
> Some SIS chipsets hang the machine when you migrate irq 0 to another
> CPU. It's better to keep that Also I wouldn't be
> OTOH, the accounting hook would allow us to remove the IRQ#0 -> CPU#0
> restriction. Not sure whether it's worth the trouble.
Some SIS chipsets hang the machine when you migrate irq 0 to another
CPU. It's better to keep that Also I wouldn't be surprised if there are some
other assumptions
On Mon, 1 Oct 2007, Andi Kleen wrote:
>
> > IRQ_NOBALANCING is not preventing cpu unplug. It moves the affinity to the
> > next CPU, but the check in NMI watchdog for CPU == 0 would not longer
> > work.
>
> That cannot happen right now because cpu_disable() on both i386/x86-64
> reject CPU #0.
> IRQ_NOBALANCING is not preventing cpu unplug. It moves the affinity to the
> next CPU, but the check in NMI watchdog for CPU == 0 would not longer
> work.
That cannot happen right now because cpu_disable() on both i386/x86-64
reject CPU #0. So just setting IRQ_NOBALANCING is sufficient and
On Mon, 1 Oct 2007, Arjan van de Ven wrote:
> > > I already did this here by checking for cpu != 0. But it also needs
> > > either tracking or forbidding migrations of irq 0. I can take care
> > > of the patch.
> >
> > I was thinking about the same fix. On i386 we already have the irq
> >
On Mon, Oct 01, 2007 at 12:56:26PM -0700, Arjan van de Ven wrote:
> On Mon, 1 Oct 2007 21:27:39 +0200 (CEST)
>
> > > I already did this here by checking for cpu != 0. But it also needs
> > > either tracking or forbidding migrations of irq 0. I can take care
> > > of the patch.
> >
> > I was
On Mon, Oct 01, 2007 at 12:56:26PM -0700, Arjan van de Ven wrote:
> On Mon, 1 Oct 2007 21:27:39 +0200 (CEST)
>
> > > I already did this here by checking for cpu != 0. But it also needs
> > > either tracking or forbidding migrations of irq 0. I can take care
> > > of the patch.
> >
> > I
On Mon, 1 Oct 2007 21:27:39 +0200 (CEST)
> > I already did this here by checking for cpu != 0. But it also needs
> > either tracking or forbidding migrations of irq 0. I can take care
> > of the patch.
>
> I was thinking about the same fix. On i386 we already have the irq
> migration /
On Mon, 1 Oct 2007, Andi Kleen wrote:
> On Monday 01 October 2007 20:54:21 Thomas Gleixner wrote:
> > On Mon, 1 Oct 2007, Andi Kleen wrote:
> >
> > > On Wednesday 26 September 2007 20:03:12 David Bahi wrote:
> > > > Thanks to tglx and ghaskins for all the help in tracking down a very
> > > >
On Monday 01 October 2007 20:54:21 Thomas Gleixner wrote:
> On Mon, 1 Oct 2007, Andi Kleen wrote:
>
> > On Wednesday 26 September 2007 20:03:12 David Bahi wrote:
> > > Thanks to tglx and ghaskins for all the help in tracking down a very
> > > early nmi_watchdog crash on certain x86_64 machines.
>
On Mon, 1 Oct 2007, Andi Kleen wrote:
> On Wednesday 26 September 2007 20:03:12 David Bahi wrote:
> > Thanks to tglx and ghaskins for all the help in tracking down a very
> > early nmi_watchdog crash on certain x86_64 machines.
>
> The patch is totally bogus. irq 0 doesn't say anything about
On Wednesday 26 September 2007 20:03:12 David Bahi wrote:
> Thanks to tglx and ghaskins for all the help in tracking down a very
> early nmi_watchdog crash on certain x86_64 machines.
The patch is totally bogus. irq 0 doesn't say anything about whether
the current CPU still works or not. You
On Wednesday 26 September 2007 20:03:12 David Bahi wrote:
Thanks to tglx and ghaskins for all the help in tracking down a very
early nmi_watchdog crash on certain x86_64 machines.
The patch is totally bogus. irq 0 doesn't say anything about whether
the current CPU still works or not. You always
On Mon, 1 Oct 2007, Andi Kleen wrote:
On Wednesday 26 September 2007 20:03:12 David Bahi wrote:
Thanks to tglx and ghaskins for all the help in tracking down a very
early nmi_watchdog crash on certain x86_64 machines.
The patch is totally bogus. irq 0 doesn't say anything about whether
On Monday 01 October 2007 20:54:21 Thomas Gleixner wrote:
On Mon, 1 Oct 2007, Andi Kleen wrote:
On Wednesday 26 September 2007 20:03:12 David Bahi wrote:
Thanks to tglx and ghaskins for all the help in tracking down a very
early nmi_watchdog crash on certain x86_64 machines.
The
On Mon, 1 Oct 2007, Andi Kleen wrote:
On Monday 01 October 2007 20:54:21 Thomas Gleixner wrote:
On Mon, 1 Oct 2007, Andi Kleen wrote:
On Wednesday 26 September 2007 20:03:12 David Bahi wrote:
Thanks to tglx and ghaskins for all the help in tracking down a very
early nmi_watchdog
On Mon, 1 Oct 2007 21:27:39 +0200 (CEST)
I already did this here by checking for cpu != 0. But it also needs
either tracking or forbidding migrations of irq 0. I can take care
of the patch.
I was thinking about the same fix. On i386 we already have the irq
migration / balancing of irq
On Mon, Oct 01, 2007 at 12:56:26PM -0700, Arjan van de Ven wrote:
On Mon, 1 Oct 2007 21:27:39 +0200 (CEST)
I already did this here by checking for cpu != 0. But it also needs
either tracking or forbidding migrations of irq 0. I can take care
of the patch.
I was thinking
On Mon, Oct 01, 2007 at 12:56:26PM -0700, Arjan van de Ven wrote:
On Mon, 1 Oct 2007 21:27:39 +0200 (CEST)
I already did this here by checking for cpu != 0. But it also needs
either tracking or forbidding migrations of irq 0. I can take care
of the patch.
I was thinking about the
On Mon, 1 Oct 2007, Arjan van de Ven wrote:
I already did this here by checking for cpu != 0. But it also needs
either tracking or forbidding migrations of irq 0. I can take care
of the patch.
I was thinking about the same fix. On i386 we already have the irq
migration / balancing
IRQ_NOBALANCING is not preventing cpu unplug. It moves the affinity to the
next CPU, but the check in NMI watchdog for CPU == 0 would not longer
work.
That cannot happen right now because cpu_disable() on both i386/x86-64
reject CPU #0. So just setting IRQ_NOBALANCING is sufficient and both
On Mon, 1 Oct 2007, Andi Kleen wrote:
IRQ_NOBALANCING is not preventing cpu unplug. It moves the affinity to the
next CPU, but the check in NMI watchdog for CPU == 0 would not longer
work.
That cannot happen right now because cpu_disable() on both i386/x86-64
reject CPU #0. So just
OTOH, the accounting hook would allow us to remove the IRQ#0 - CPU#0
restriction. Not sure whether it's worth the trouble.
Some SIS chipsets hang the machine when you migrate irq 0 to another
CPU. It's better to keep that Also I wouldn't be surprised if there are some
other assumptions about
On Tue, 2 Oct 2007, Andi Kleen wrote:
OTOH, the accounting hook would allow us to remove the IRQ#0 - CPU#0
restriction. Not sure whether it's worth the trouble.
Some SIS chipsets hang the machine when you migrate irq 0 to another
CPU. It's better to keep that Also I wouldn't be surprised
On Tue, 2 Oct 2007 00:47:12 +0200 (CEST)
Thomas Gleixner [EMAIL PROTECTED] wrote:
On Tue, 2 Oct 2007, Andi Kleen wrote:
OTOH, the accounting hook would allow us to remove the IRQ#0 -
CPU#0 restriction. Not sure whether it's worth the trouble.
Some SIS chipsets hang the machine when
Thomas Gleixner wrote:
On Tue, 2 Oct 2007, Andi Kleen wrote:
OTOH, the accounting hook would allow us to remove the IRQ#0 - CPU#0
restriction. Not sure whether it's worth the trouble.
Some SIS chipsets hang the machine when you migrate irq 0 to another
CPU. It's better to keep that
On Tue, 02 Oct 2007 07:56:24 +0300
Mika Penttilä [EMAIL PROTECTED] wrote:
Here I have with stock FC7 (2.6.22.9-91) kernel :
0: 107835 133459760 IO-APIC-edge timer
fwiw this is entirely done by the hardware; no irq balancer has touched
this one (fc7 has the new irqbalancer
Agreed.
I just got a x8664-hrt report, where I found the following oddity:
0: 1197 172881 IO-APIC-edge timer
That's one of those infamous AMD C1E boxen. Strange, all my systems have
IRQ#0 on CPU#0 and nowhere else. Any idea ?
Hmm, in lowestpriority mode it would be
Thanks to tglx and ghaskins for all the help in tracking down a very
early nmi_watchdog crash on certain x86_64 machines.
This modifies nmi_watchdog_tick behavior for
x86_64 arch to consider both timer and hpet IRQs
just as the i386 arch does.
Signed-off-by: David Bahi <[EMAIL PROTECTED]>
---
Thanks to tglx and ghaskins for all the help in tracking down a very
early nmi_watchdog crash on certain x86_64 machines.
This modifies nmi_watchdog_tick behavior for
x86_64 arch to consider both timer and hpet IRQs
just as the i386 arch does.
Signed-off-by: David Bahi [EMAIL PROTECTED]
---
48 matches
Mail list logo
