9 Oct
2003
9 Oct
'03
3:02 p.m.
Hi,
I may be barking up the wrong tree about APIC, there are other acronyms that
may be at work here ;)....
But, to conclude, I think the source of my argument is probably here on the
list. If memory serves me it was Mark Knecht (who also had written the text
on the page below) that had commented about it earlier...
The reasoning (i think) was that IRQ priority and IRQ sharing are the two
important things to look out for. With APIC you get enough IRQ's, but you
don't know which priority they have to each other which is fatal.
Cool! I didn't know it was possible to device such a program. Have to check it
out!
/Robert
Hi,
I'm pretty sure I've read that APIC is a no no and should be avoided.
I'd like to see what you read. In my experience it either works or it
doesn't. One can't avoid using APIC interrupts in a dual-processor
system. Here's a
link to some interesting info about "normal" IRQs in a PC. There
is more to it than just having an "OWN" IRQ, they have different
priorities.
http://myweb.cableone.net/eviltwin69/Arcana.html#IRQs
See also (the source)
http://www.djcj.org/LAU/guide/Low_latency-Mini-HOWTO.php3
/Robert
Yes, that HOWTO has good info, as far as it goes. One thing I would add
though, is that when using non-APIC interrupts the interrupt priority is
not fixed in stone (or silicon, as it were). Using the program
"irqtune" one can change interrupt priorities (see
http://www.best.com/~cae/irqtune ). I havn't used irqtune in a while, not since kernel 2.2 days, so I'm not altogether
sure that it works
correctly with 2.4.x kernels. On Debian it is in the "hwtools"
package. Hmm, I just tried it on a box with a 2.4.21+lowlatency kernel
and it seems that it worked, though it gave some warnings. I can't
really test if the IRQ priorities have changed though. YMMV.
wes