Speaking of disagreements, I've seen two groups of thought on using 'hdparm' to speed up a hard drive. What is the final verdict? chaz ----- Original Message ----- From: "Clemens Ladisch" <clemens@xxxxxxxxxx> To: "A list for linux audio users" <linux-audio-user@xxxxxxxxxxxxxxxxxx> Sent: Friday, July 16, 2004 12:06 PM Subject: Re: [linux-audio-user] APIC is bad? > Mark Knecht wrote: > > No, you are exactly right. Clemens and I have some small technical > > disagreements on this subject. We had a conversation that was > > interesting but I think didn't yield any clear answers, at least in my > > mind, so I freely admit I'm still confused on the subject. > > > > [...] As I remember the conversation the interrupt order was from > > the highest interrupt number and going down from there, so if > > Florin sees 25 interrupts, then #25 gets serviced first and that > > would be where I'd want my sound card, if I could get it there. > > What I tried to explain was that the priority is not determined by the > interrupt number but by the interrupt vector number. > > Well, let's see if my explanation isn't too muddy this time :-) > > > The routing of interrupts from the hardware to the driver happens on > three levels. > > First, there are the (PCI) interrupt lines, which are the input pins > of the interrupt controller chip. These are usually called > PIRQA/B/C... The only way to choose the interrupt line for the sound > card is to put it into another PCI slot. The interrupt line of > integrated devices is usually fixed. > > The interrupt controller (PIC or I/O-APIC) has a number of hardware > interrupts (PIC 16, I/O-APIC 24? or more). Each interrupt line is > mapped to one interrupt. In PIC mode, the routing of interrupt line > to interrupt number can be chosen by software (but is done by the BIOS > in practice). In I/O-APIC mode, the routing of interrupt lines to > interrupts is fixed: each PCI interrupt line gets one of the > interrupts above 15. > These are the interrupt numbers shown in /proc/interrupts. > > The interrupts are mapped to interrupt vectors. Intel CPUs have 256 > of them, but some are used for other purposes than hardware > interrupts. The interrupt vector numbers are chosen by the Linux > kernel, and are fairly well hidden, but you can find them in the dmesg > output if I/O-APIC is enabled. > > > When the I/O-APIC is not enabled, interrupt priority is determined by > the interrupt number (0 1 8 9 10 11 12 13 14 15 3 4 5 6 7). > > When the I/O-APIC is enabled, interrupt priority is determined by the > interrupt vector number (lower vectors numbers have higher priority). > > (My patch to change vector numbers doesn't work with current kernels.) > > > Regards, > Clemens > >
