Re: [PATCH] 2.5.68 Fix IO_APIC IRQ assignment bug

[Linus Torvalds]

In article <[e-mail]>,
Chuck Ebbert  <[e-mail]> wrote:
>
> I found this while trying to forward-port my .66 patch to make
>the redirect table look like this:

Btw, why would you _want_ your redirect table to look like that?

> NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:   
> 00 001 01  0    0    0   0   0    1    1    E7     <== timer at level E
> 01 001 01  0    0    0   0   0    1    1    30     <== start at 30, not 31

Starting at 31 is better, because..

> 02 000 00  1    0    0   0   0    0    0    00
> 03 001 01  0    0    0   0   0    1    1    38
> 04 001 01  0    0    0   0   0    1    1    40
> 05 001 01  0    0    0   0   0    1    1    48
> 06 001 01  0    0    0   0   0    1    1    50
> 07 001 01  0    0    0   0   0    1    1    58
> 08 001 01  0    0    0   0   0    1    1    60
> 09 001 01  0    0    0   0   0    1    1    68
> 0a 001 01  0    0    0   0   0    1    1    70
> 0b 001 01  0    0    0   0   0    1    1    78
> 0c 001 01  0    0    0   0   0    1    1    88     <== only one device at 8

Then we'd have devices at 81 and 89 (two per block of 16 is ok, but 80
isn't ok because we use that for system calls).

And having two devices in the 8x series means that it takes more irq
sources to overflow and start to re-use the 3x block - and we want to
delay re-using the 3x block as long as possible due to the silly "only
one pending irq per block" rule that some intel APIC's have.

So that's why FIRST_DEVICE_VECTOR is normally 31 - because it gives a
nicer pattern for the first round of allocations, and that's the common
case (machines with hundreds of APIC irq sources are still rare, the
common case is a single IOAPIC with 24 or so pins).

		Linus