In keeping with my other projects, I'm working on `burnAPIC`
to test out APIC functionality. I've finally got the APIC
interrupt command register working -- in a kernel module,
of course. I'm a little behind on kernels -- 2.2.13.
I stick in `movl $0x000840D0, 0xFFFFE300` and I get a nice
spurrious interrupt D0h on each CPU. The irq.c printk's work
fine and tell me all about it (funny number printed, though).
The problem is: it works too well! The spurrious interrupts
repeat ONCE after a short while (I have my own printk that
prints in the middle). Both CPUs repeat, and in the same
order. Very pretty, too, without any interlacing of printk's.
But why should they repeat? I get four spurrious interrupts
for one `movl`. Two I can understand, but four is too many!
It gets wierder: if I put TWO `movl`s in back-to-back, or
with some register-register op in between, NOTHING happens.
Both spurrious interrupts I'm trying to generate dissappear.
Not a good thing. What would happen if they were REAL ints?
Now if I space the `movl`s out a bit by an instruction with
a read or better yet, a write, then I get the same as above:
two spurrious from the first `movl`, two from the second,
my printk marker, then the four ghosts. All nicely in order.
This certainly is unexpected behaviour. Maybe more than
one thing is broken here. I'm pretty sure there's nothing
foolish like made the remapped APIC page cachable, but the
APIC acknowledgement might need some work. And the Intel
hardware might have the "feature" of totally missing both
interrupts that occur too close together. This is NOT a
good thing, but might be unavoidable with edge-triggered ints.
-- Robert author `cpuburn` http://users.ev1.net/~redelm
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 21:00:26 EST