Dave08 wrote:
What I have tried
- Yes, I have checked if I had set up the IVT correctly, and I did.
- Yes, I did call sti to re-enable interrupts.
- And yes, I am sending EOI at the end of my handlers.
So, your ISRs do not run, but the interrupt flag is set. Well, what else could it be? First order of business is going to be to establish some kind of debugger on the affected device. And you cannot read the keyboard. So how about instead of HLT, you run a busy-wait loop that prints some things every couple million TSC steps (so you RDTSC and do some things if any changes happened above the 20th bit or so)? Then you can try to find out what is going on yourself.
Not getting a PIT interrupt can be due to the PIT not making the interrupt, the PIC not receiving it, the PIC sending it to a different interrupt slot, or the CPU ignoring it. So first things first, I would check the various registers of the PIC that can be read without side effects and print them on screen. Then you can see if the PIT and keyboard interrupts are being generated. It is also possible that the IDTR contains weird values, so maybe try to print the results of "sidt" once in a while. Maybe the IVT at address 0 is not the one in use?
If you find that the interrupt is being generated, maybe create ISRs for every slot that just print "interrupt X happened" (excepting the BIOS interrupts, of course). That ought to show you where the interrupts land. You could write those as interdictors, so that the original routine is still executed after your debug print.
Dave08 wrote:
And at this point, I am too afraid to try it on other laptops, as I don't know how they might react.
It's gonna make the system spontaneously combust. In all seriousness, just try it. It is supremely unlikely that you would brick the system, and beyond that the worst that can happen is your game won't work. Oh well.