[linux-audio-user] APIC is bad? What about hdparm?
ewf at alltel.net
Fri Jul 16 13:47:44 EDT 2004
Speaking of disagreements, I've seen two groups of thought on using 'hdparm'
to speed up a hard drive. What is the final verdict?
----- Original Message -----
From: "Clemens Ladisch" <clemens at ladisch.de>
To: "A list for linux audio users" <linux-audio-user at music.columbia.edu>
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.)
More information about the Linux-audio-user