[Real mode] PIT and Keyboard IRQs not firing on laptop

[Dave08]

Hi all,

I am currently developing a small program purely in 16-bits assembly. This program is a sort of game working with software rendering using video mode 0x13.

I tested it on many emulators : QEMU, Bochs, VirtualBox, VMWare... They all work the same. I event tested it on an old desktop PC with UEFI and CSM for old-style booting, and it works! Until I decided to test it on another physical machine, a Toshiba Satellite L670 laptop.

What I see
The splash screen is displayed correctly. What this means is a lot : Back buffer over the 1 MiB limit works, font loading using int 0x13 works, and segments have all been loaded correctly. Hurray!
Although, after that, I have added a sort of "sleep" call which tells the game to wait for a second. The way this works is by trapping the CPU into a loop with a hlt, and testing the number of remaining frames.
Meanwhile, IRQ0 (the PIT) is triggered 30 times a second and decrements this counter. So, execution blocks until this countdown reaches 0.
But on the laptop I mentioned above, it simply hangs, and I can't figure out why. It doesn't go past the splash screen, even though everything else worked until this point.

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.
I also tried removing ALL halts and wait calls to jump directly to the game's main loop. I do see the scene, the player's health, everything is as it should be. BUT, the keyboard is not responding. I have tried pressing all the keys I have bound to some action, and they all do nothing.
There are also some moving elements in the scene, which are staying absolutely still, which in turn means that the PIT's interrupt is not being picked up...

This is where I am currently. The bootloader loads the rest of the game fine. The game sets itself up, renders the splash screen, and then hangs on hlt, only on this Toshiba laptop. With all the tests I made, it does seem like my ISRs are not being called. And at this point, I am too afraid to try it on other laptops, as I don't know how they might react.

Any help would be apreciated.
Thanks!

[nullplan]

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.

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.

[Gigasoft]

Possible causes:
- you are sending an EOI for an interrupt you did not handle, causing an endless stream of interrupts.
- interrupts are masked.
- a timer interrupt was somehow not handled.

[Octocontrabass]

- Yes, I have checked if I had set up the IVT correctly, and I did.

Care to elaborate? There's a lot of things you could be doing when you say "set up the IVT".

[Dave08]

I have tried explicitly setting the Master PIC mask to 0b10111100 (PIT, keyboard and floppy IRQs active), but it does not change anything.

- Yes, I have checked if I had set up the IVT correctly, and I did.

Care to elaborate? There's a lot of things you could be doing when you say "set up the IVT".

About setting the IVT, I have done this for the PIT :

Code: Select all

mov word [0x20], _isr_timer
mov word [0x22], 0

...

_isr_timer:
    pusha
    ...

    mov al, 0x20
    out 0x20, al
    popa
    iret

I know it's correct, because it works on emulators and on my physical desktop. I also know that my laptop sets the IVT to memory location 0x0000:0x0000 because I tried hooking a handler for the breakpoint interrupt (INT 3) which simply set the first pixel red in my framebuffer. I wrote int 3 and I do see the pixel.

I am certain I am sending the right EOIs when needed, as they are always called at the end of my handlers before iret.
I don't have to send anything to 0xA0, as I'm not using any IRQs from the slave PIC.

[Octocontrabass]

What happens if, instead of sending the EOI yourself, you jump to the original timer ISR?

What happens if you leave the timer at its default settings instead of programming it for 30Hz?