On Fri, 2008-11-21 at 15:40 +0100, Arnd Bergmann wrote:
> On Friday 21 November 2008, Benjamin Herrenschmidt wrote:
> > Oh just that for powermac for example, I know I'm resetting the thing,
> > so can't rely on init values, and on some BML embedded boxes too, while
> > on things like cell I don't
On Friday 21 November 2008, Benjamin Herrenschmidt wrote:
> Oh just that for powermac for example, I know I'm resetting the thing,
> so can't rely on init values, and on some BML embedded boxes too, while
> on things like cell I don't off hand know what the right CPU number is
> to hit the right C3
On Thu, 2008-11-20 at 18:23 +0100, Arnd Bergmann wrote:
> Kexec/kdump currently fails on the IBM QS2x blades when the kexec happens
> on a CPU other than the initial boot CPU. It turns out that this is the
> result of mpic_init trying to set affinity of each interrupt vector to the
> current boot
Kexec/kdump currently fails on the IBM QS2x blades when the kexec happens
on a CPU other than the initial boot CPU. It turns out that this is the
result of mpic_init trying to set affinity of each interrupt vector to the
current boot CPU.
As far as I can tell, the same problem is likely to exist
On Wed, 2008-11-19 at 14:50 +0100, Arnd Bergmann wrote:
> This patch implements the first approach, because it can work on
> machines that have a secondary controller that needs to deliver
> interrupts to a destination other than CPU 0. The disadvantage
> is that it requires the system to set up th
Kexec/kdump currently fails on the IBM QS2x blades when the kexec happens
on a CPU other than the initial boot CPU. It turns out that this is the
result of mpic_init trying to set affinity of each interrupt vector to the
current boot CPU.
As far as I can tell, the same problem is likely to exist
