[lkml]   [2002]   [Sep]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: APIC IRQs
On Monday 16 September 2002 10:48 am, Mark Knecht wrote:
> Hi,
> Sorry for the intrusion. I'm working in the Linux audio areas and am
> looking for information on how IRQ priorities are handled when using APIC
> under Linux. Google searches have not yielded much for me. I'm a hardware
> guy, so code stubs are probably not the best answer, but I'm interested in
> most anything on the subject.
> Can someone point me towards any non-developer information on this
> subject? HOWTOs, explanations, whatever? Mostly just looking for how to
> best configure audio cards and disk controllers to get the lowest latencies
> in this specific application. I understand the traditional model quite
> well, so even a doc that talked about the differences would be very
> helpful.
> Thanks in advance!
> With best regards,
> Mark


The current Linux kernel does not use the Task Priority Register (TPR) to set
interrupt priority levels in the classic Unix splX() fashion. Instead, the
TPR is set to zero at boot and left there for the life of the kernel. (I
have a patch out to change this.)

Linux interrupt routines are expected to be fast and return quickly, so the OS
does do not use the priority hardware or enable interrupts during their
execution. One notable exception is the IDE interrupt handler when operating
in port I/O mode. It will re-enable interrupts while it is servicing an IDE

For APICs, when two interrupts are present when interrupts are enabled, the
one with the highest interrupt vector number will be taken first. Vectors
are statically assigned to the PCI slots, starting at 0x40 or 0x41. So, the
last PCI interrupt source in the MPS table will be the highest priority.
However, I don't think that the MPS table spec specifies any kind of order.
The interrupt source records are sorted however the BIOS wishes. Usually,
they will be sorted by slot number, but that is not guaranteed.

ACPI's ordering is more predictable. The last pin of the last I/O APIC
mentioned in the PCI Routing Table (PRT) will have the highest vector number.

James Cleverdon
IBM xSeries Linux Solutions
{jamesclv(Unix, preferred), cleverdj(Notes)} at us dot ibm dot com

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:28    [W:0.051 / U:1.656 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site