[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20071001155202.56c348c8@laptopd505.fenrus.org>
Date: Mon, 1 Oct 2007 15:52:02 -0700
From: Arjan van de Ven <arjan@...radead.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Andi Kleen <ak@...e.de>, David Bahi <dbahi@...ell.com>,
LKML <linux-kernel@...r.kernel.org>,
linux-rt-users@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Ingo Molnar <mingo@...e.hu>,
Gregory Haskins <GHaskins@...ell.com>
Subject: Re: nmi_watchdog fix for x86_64 to be more like i386
On Tue, 2 Oct 2007 00:47:12 +0200 (CEST)
Thomas Gleixner <tglx@...utronix.de> 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 Also I wouldn't be surprised if there
> > are some other assumptions about this elsewhere.
> >
> > Ok in theory it could be done only on SIS, but that probably would
> > really not be worth the trouble
>
> 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 ?
2 things;
the current irq balancers don't balance the timer interrupt, in fact
they'll leave it alone (so the chipset might balance)
older ones pin it to cpu 0 or rotate it....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists