[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090607143356.GE4547@lenovo>
Date: Sun, 7 Jun 2009 18:33:56 +0400
From: Cyrill Gorcunov <gorcunov@...il.com>
To: mingo@...hat.com, hpa@...or.com, linux-kernel@...r.kernel.org,
yinghai@...nel.org, tglx@...utronix.de, mingo@...e.hu
Subject: Re: [tip:irq/numa] x86, apic: Fix dummy apic read operation
together with broken MP handling
[tip-bot for Cyrill Gorcunov - Sun, Jun 07, 2009 at 02:24:31PM +0000]
| Commit-ID: 103428e57be323c3c5545db8ad12667099bc6005
| Gitweb: http://git.kernel.org/tip/103428e57be323c3c5545db8ad12667099bc6005
| Author: Cyrill Gorcunov <gorcunov@...nvz.org>
| AuthorDate: Sun, 7 Jun 2009 16:48:40 +0400
| Committer: Ingo Molnar <mingo@...e.hu>
| CommitDate: Sun, 7 Jun 2009 16:08:05 +0200
|
| x86, apic: Fix dummy apic read operation together with broken MP handling
|
Hi Ingo, this commit will fix your case but to be fair
I'm a bit scared of disable_apic variable now spreading
all over the files. I've checked Makefile's and Kconfig
for situation when SMP turned on and apic.c is not compiled
(from hw POV on x86 it should not be possible since SMP
requires APIC chip but dunno -- just something from
inside of me says there could be a hidden problem).
I was also thinking about some common bitfiels for
apic features -- like one bit to figure out if
it was disabled via boot line, one bit for x2apic
mode enabled and so on. We have the cpu_has_...
helpers maybe the same for apic could be implemented?
How do you think?
-- Cyrill
--
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