[linux-audio-user] APIC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Clemens,
   Hi. Thanks for the response. It's very helpful and good information.
Since I think there is still some differences between your software and my
hardware points of view so I'll continue to ask a few questions and document
my points below. No *major* disagreements with what you wrote, maybe one
minor one at the very end. Mostly this is still clarification and
comparison.

- Mark

<SNIP>
>
> Lower-priority interrupts don't automatically get suppressed, or much
> delayed.

Possibly true, or should be if software is designed right.

> The priority is simply used to choose between several
> interrupts occuring at the same time, which happens almost never.

Speaking as a hardware designer who has worked on chipset and many different
I/O controller technologies (SCSI, EIDE, Ethernet, 1394, USB and legacy) I
can assure you that this is not always true. None the less, it only takes
one delay to create an xrun and blow a live recording.

>
> > and when a piece of Ethernet driver code crashes nothing would be
> > able to break in. Not good.
>
> Apparently, you've never developed a driver. ;-)  When any interrupt
> handler crashes, Linux prints the following dreaded message after the
> usual report:
> | Kernel panic: Aiee, killing interrupt handler!
> | In interrupt handler - not syncing
> and _everything_ halts -- no interrupts, no keyboard, no Alt+SysRq.
> All you can do is a hard reset and be delighted at what fsck tells
> you.

;-) OK, now it's extremely well known fact that I'm not a programmer. Why
would you think there was *any* chance I'd ever written a driver? ;-)
(Though I have managed Windows SCSI driver programmers and have some
first-person background...)

<SNIP>
>
> >  NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
> >  00 000 00  1    0    0   0   0    0    0    00
> >  14 000 00  1    0    0   0   0    0    0    00
> >  17 000 00  1    0    0   0   0    0    0    00

<SNIP>
>
> Indeed, IRQ22 does have the highest priority in your system.
>
> (BTW, 17 = 0x11)

It was not marked as such in my system. 17 was marked 0x00. None the less,
it wouldn't change thing much. (0x00 vs. 0x11)

>
> And in APIC mode, Linux doesn't use interrupt 0 for the timer (vector
> 0 is reserved, so interrupts 0, 20, and 23 are unused).  Instead, the
> local APIC timer is used (this is the "LOC:" line in
> /proc/interrupts).

Ah! Ok, that's good info although my system sort of makes it look like LOC:
and IRQ0: are the same thing since they always have the same number of
interrupts.

<SNIP>

>
> The APIC mode affects PCI interrupts only.  The so-called 'legacy'
> devices still use interrupts below 16, and the mapping from device to
> interrupt number doesn't change.  (Actually, it can be changed, but
> the configuration of the Super-I/O chip is done only by the BIOS.)

OK, so then the real question is how does APIC mode change the relationship
between all of the older 'legacy' devices and the PCI bus. It's not
difficult to show, so let's map this out, old style vs. APIC style. I'll
show the highest priority interrupts at the top of the list (legacy style)
since I expect that someone like Jan Depner might be reading this and
possibly someday it would make it onto his pages. I'll add an APIC column
for what I think I'm reading in your words and then we'll correct my
misunderstanding or your POV.

	Legacy Function		APIC Style
IRQ255
...
IRQ16					PCI slots??????

IRQ0	Timer				Timer
IRQ1	Keyboard			Keyboard
IRQ2	Cascade->IRQ8-15		Cascade
IRQ8	RTC				RTC
IRQ9	PCI
IRQ10	PCI
IRQ11	PCI/VGA
IRQ12	PS/2 Mouse			PS/2 Mouse
IRQ13	(Old FPU)
IRQ14	IDE0				IDE0
IRQ15	IDE1				IDE1
IRQ3	Com2/PCI			Com2
IRQ4	Com1/PCI			Com1
IRQ5	Parallel/PCI		Parallel
IRQ6	Floppy			Floppy
IRQ7	Printer/PCI			Printer

Now, my point is that I do not think/believe/agree that the PCI slots are
intended to have higher priority than the Timer or the keyboard. I could
certainly be wrong, but to me it doesn't make sense. On the other hand, I
could certainly agree with the idea that all of the APIC stuff could link in
around IRQ9 (like it does on an XP machine) with a second level of priority
assigned by the vector in the table.

I am just not sure which you are suggesting is true.

Notes for casual readers:
a) I add PCI to IRQs 3, 4, 5 & 7 from personal experience. Not all
motherboards support this.

b) I do not show onboard devices that may share interrupts, such as USB, USB
2.0 or 1394. Consult your motherboard manual or 'lspci -v' for more info on
your system. Manufacturers are free to rearrange most anything if they don't
care about DOS compatibility.

c) VGA interrupts are often shared with a PCI slot. On many systems the
interrupt number can be reassigned. On many of my legacy systems I run it at
IRQ11.

<SNIP>
>
>
> Well, I think all these technical details obscured the point I was
> trying to make, which is that, for all practical purposes, interrupt
> priorities don't matter when tuning a sound card.

I think you wouldn't say this if you placed an active Gigabit Ethernet
adapter at interrupt 22 and a sound card at interrupt 21. Maybe that's not
practical enough

What about a 10/100 Ethernet at 22, a 1394 adapter at 21, maybe a USB
controller at 20 and your sound card at 19. Over time my experience is that
you will see xruns. Change the order to sound card at 22 and you see fewer
xruns. Or that's my experience.

>
> Regards,
> Clemens

With best regards to you too!

- Mark



[Index of Archives]     [Linux Sound]     [ALSA Users]     [Pulse Audio]     [ALSA Devel]     [Sox Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux