Skip to contentSkip to conversation

2.5.68 Fix IO_APIC IRQ assignment bug

PATCH Chuck Ebbert 2 participants 2 messages Apr 21, 2003 – Apr 22, 2003

lore
Share & tools
lore
#0 lore raw

Oops, meant to send this to l-k:

Quoted 3 lines · Linus Torvalds
Quoted 3 lines

Looks like the fix for the "ran out of interrupt sources" panic has a problem. It will eventually assign a device the same IRQ number as the first system vector, i.e. the local APIC timer.

...

Quoted 1 line

Did you actually see this on hardware?

In my dreams. :) But someone must have such hardware or the panic
wouldn't have been removed...

Only reason I found it at all is I had changed the exact same lines
in my patch (and mine had a much bigger bug than that.)

Quoted 5 lines

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

Quoted 3 lines

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

The patch does two things:

1. Reserves all of priority level E for the timers -- legacy timer at E7, first system vector DF. This is might be worth doing (but first system vector should be E0.)

2. Starts assigning devices at 0x30 instead of 0x31.

(1) is probably worth doing (first system vector should be E0, though.)

Quoted 1 line

Starting at 31 is better, because..

...

Quoted 5 lines

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

But doesn't IRQ 0x80, even though it is software-initiated, contend
with 'real' device interrupts at priority 8, which would mean there are three possible sources (80, 81 and 89?) That's what I was assuming...

------
Chuck

------
Chuck

#1 lore raw
Quoted 3 lines · Chuck Ebbert

But doesn't IRQ 0x80, even though it is software-initiated, contend
with 'real' device interrupts at priority 8, which would mean there are three possible sources (80, 81 and 89?) That's what I was assuming...

Problems are with local APIC hardware (with queueing arriving IRQ
messages); "int 0x80" doesn't go through the APIC.

Signature · 3 lines
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: [email protected], PGP key available        +