Re: default IRQ affinity change in v2.6.27 (breaking several SMPPPC based systems)

[Scott Wood]

Chris Snook wrote:
> Scott Wood wrote:
> > Kumar Gala wrote:
> > > So why not just have x86 startup code set irq_default_affinity = 
> > > CPU_MASK_ALL than?
> >
> > That doesn't really solve the problem, as a user could still manually 
> > set an invalid affinity.  The MPIC driver should reduce the affinity 
> > itself to what the hardware can handle.
>
> Does the MPIC code actually allow that to happen?

As far as I can tell, though I haven't tested it.

> I can't quite tell, but I noticed this:
>
> [csnook@bernoulli sysdev]$ fgrep '#ifdef CONFIG_' mpic.c | sort -u
> #ifdef CONFIG_IRQ_ALL_CPUS
> #ifdef CONFIG_MPIC_BROKEN_REGREAD
> #ifdef CONFIG_MPIC_U3_HT_IRQS
> #ifdef CONFIG_MPIC_WEIRD
> #ifdef CONFIG_PCI_MSI
> #ifdef CONFIG_PM
> #ifdef CONFIG_PPC32     /* XXX for now */
> #ifdef CONFIG_PPC_DCR
> #ifdef CONFIG_SMP
>
> Do any of those config options (or combinations thereof) imply an MPIC 
> that can't handle an IRQ masked to multiple CPUs?  If so, this can be 
> fixed rather easily at build time, without having to muck around with 
> arch-specific initialization code.

I don't think so, and in any case it should be detected at runtime from 
the device tree.

-Scott

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/