Messages in this thread | | | From | (Linus Torvalds) | Subject | Re: [PATCH] 2.5.68 Fix IO_APIC IRQ assignment bug | Date | Sun, 20 Apr 2003 23:06:05 +0000 (UTC) |
| |
In article <200304201811_MC3-1-3537-1648@compuserve.com>, Chuck Ebbert <76306.1226@compuserve.com> 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 - 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/
| |