On Sun, May 30, 2010 at 12:56:26PM +0000, Blue Swirl wrote: > >> Well, I'd like to get the test program also trigger it. Now I'm getting: > >> apic: write: 00000350 = 00000000 > >> apic: apic_reset_irq_delivered: old coalescing 0 > >> apic: apic_local_deliver: vector 3 delivery mode 0 > >> apic: apic_set_irq: coalescing 1 > >> apic: apic_get_irq_delivered: returning coalescing 1 > >> apic: apic_reset_irq_delivered: old coalescing 1 > >> apic: apic_local_deliver: vector 3 delivery mode 0 > >> apic: apic_set_irq: coalescing 0 > >> apic: apic_get_irq_delivered: returning coalescing 0 > >> apic: apic_reset_irq_delivered: old coalescing 0 > >> apic: apic_local_deliver: vector 3 delivery mode 0 > >> apic: apic_set_irq: coalescing 0 > >> So interrupt is _alway_ coalesced. If apic_get_irq_delivered() returns 0 it means the interrupt was not delivered.
> >> It looks like some other IRQs cause the coalescing, because also > >> looking at RTC code, it seems it's not possible for RTC to raise the > >> IRQ (except update IRQ, alarm etc.) without calling > >> apic_reset_irq_delivered(). > >> > >> I've attached my test program. Compile: > >> gcc -m32 -o coalescing coalescing.S -ffreestanding -nostdlib -Wl,-T > >> coalescing.ld -g && objcopy -Obinary coalescing coalescing.bin > >> > >> Run: > >> qemu -L . -bios coalescing.bin -no-hpet -rtc-td-hack > >> > > The application does not work for me. Looks like it fails to enter > > protected mode. $pc jumps from 0x00000000fffffff0 to 0x00000000000f003e > > and back. > > Strange. Here's a working binary. > Your binary works here too. What compiler are you using? -- Gleb.