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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
