IRQ1 not delivered while CPU hlt'ed

[durand]

Hooray for Mega-Tokyo again. I posted a message in other forums (after a lot of trying) and now I can't reply or login again anymore... so here is my question:

Hi there,

I've been really struggling with a problem the last week or two and I've gone looking everywhere for it. I've modified the way I handle IRQs, done checks at every point, etc.

Basically, I have an idle thread which does a 'hlt'. So the CPU is waiting for an interrupt to wake it up. IRQ1 is triggered when I press a key but the IRQ1 does not wake up the CPU. IRQ12 does fire when I move the mouse and it correctly wakes up the CPU. If I press several keys and then move the mouse to wake the CPU, IRQ1 fires successfully for the all the previous keystrokes I did as it should have done previously.

Then if I remove the 'hlt' from the idle thread and replace it with an infinite loop (while 1==1 continue), then IRQ1 is delivered as it is supposed to be delivered - immediately.

IRQ1 is not masked. Interrupts are enabled. It only happens on *some* computers and vmware. I've followed all examples of PIC/APIC/IOAPIC/NMI/etc initialization and the problem remains.

My current guess now is that the motherboard/chipset is initialized by the BIOS during boot to prevent IRQ1s being delivered to the CPU while it is hlt'ed. (Wake on keyboard? ACPI strangeness?).

Has anyone seen anything like this before?

[durand]

Pype.Clicker responded:

honnestly, no. that's the first time i hear a such thing.

Maybe indeed the system management mode does something weird, but i'd rather look for something wrong in the "End Of Interrupt" notification if i were you ...

[durand]

It is pretty odd. I've even replaced my IRQ1 handler with a simple byte read from 0x60 and an immediate ack with return. The same thing happens!

I was browsing the linux source because of this and saw that it has a "check_halt" function which checks to see if the hlt function works and gets interrupted correctly. So I think I may be stumbling across some weird bugs somewhere on some machines and virtual machines.

[Ryu]

It should resume executing after the 'hlt' instruction regardless EOI is sent. How water'd down is your code? The only thing I can think of is, maybe your thread wakes up but somehow ends up into a deadlock.

edit: This could be a deadlock in the ISR itself, before it gets the return ( 'iretd' ).

edit: Its also nice to know if your using interrupt or trap gates? Or even paste some code up.