Re: [PATCH][2.5] provisional 32-way x445 patches

Zwane Mwaikambo (zwane@linuxpower.ca)
Sat, 24 May 2003 14:47:06 -0400 (EDT)


On Fri, 23 May 2003, James Cleverdon wrote:

> -int irq_vector[NR_IRQS] = { FIRST_DEVICE_VECTOR , 0 };
> +u8 irq_vector[NR_IRQ_VECTORS] = { FIRST_DEVICE_VECTOR , 0 };
>
> static int __init assign_irq_vector(int irq)
> {
> static int current_vector = FIRST_DEVICE_VECTOR, offset = 0;
> + BUG_ON(irq >= sizeof(irq_vector)/sizeof(*irq_vector));

Can't you just skip that one (-ENOSPC)? It would oops on 32way NUMAQ. Why
don't we just fix this properly now, it looks like we might end up just
piling workarounds ontop of kludges. The intel guys were kind enough to
crank out a vector based irq handling patch and it's just what we need to
purge NR_IRQS misuse.

> */
>
> -extern int irq_vector[NR_IRQS];
> -#define IO_APIC_VECTOR(irq) irq_vector[irq]
> +/* The upper limit of irq_vector's size is 16 + sum(num_RTEs_in_IO_APICs).
> + * On 32-way x445s this is already 266 without any I/O expansion boxes.
> + * This should eventually be dynamically allocated.
> + */
> +#define NR_IRQ_VECTORS (4 * NR_IRQS)
> +extern u8 irq_vector[NR_IRQ_VECTORS];
> +#define IO_APIC_VECTOR(irq) (int)(irq_vector[irq])

This just makes the relationship between NR_IRQS and NR_IRQ_VECTORS even
more confusing. If you have one IDT, NR_IRQ_VECTORS is ~190

Zwane

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