OSDev.org

I was trying to clean up my bootloader of my OS and also write some ISRs. One of the was UD exception. Now to test it, I initially tried to break stack alignment of my keyboard ISR, hoping that when I press a key after my OS has booted, the stack will misalign and UD Exception will be raised. But, to my surprise, my system went to triple fault while booting. Immediately noticed something's wrong as I hadn't pressed a key.

I changed the PUSH with a JMP $ to make it stuck and started to dig into it with debug prints. turns out it happens in my A20 check subroutine. For some reason, when I execute an OUT instruction into port 0x64, the keyboard interrupt is raised. It made some sense as 0x64 is PS/2 related, but still why is there an interrupt when I haven't pressed a key? I used another code bit to check and my UD handler code is working correctly.

I narrowed it down to the exact instruction. OUT dx, al(dx=0x64).

One kludge you could use to get around that is disabling ints in your A20 check routine. Note, however that would mask the problem, as I suspect there may be something wrong with your A20 code. But I would have to see it first.

nexos wrote:One kludge you could use to get around that is disabling ints in your A20 check routine. Note, however that would mask the problem, as I suspect there may be something wrong with your A20 code. But I would have to see it first.

I narrowed it down to a single instruction, and it's the OUT to 0x64, reading in A20 status. That's why I didn't bother to put one instruction. And it's at the start of the code.

Also I don't think it is a new problem. I think the keyboard ISR is called anyway but as the handler isn't working yet, the ISR just exists and code is resumed. All this happens so fst I don't notice it at all, until I manually hanged the ISR.

You will get key events both when you press and release keys.

rdos wrote:You will get key events both when you press and release keys.

I know. It happens at exactly on the OUT instruction I mentioned. When I put a debug print on top, it works. And if I put one on bottom, It doesn't. That means that out instruction to PS/2 port caused an interrupt trigger, unless something horribly bad is happening.

pranavappu007 wrote:Now to test it, I initially tried to break stack alignment of my keyboard ISR, hoping that when I press a key after my OS has booted, the stack will misalign and UD Exception will be raised.

Why would a misaligned stack cause #UD?

pranavappu007 wrote:It made some sense as 0x64 is PS/2 related, but still why is there an interrupt when I haven't pressed a key?

The PS/2 keyboard controller (and its ancestor, the AT keyboard controller) raises an interrupt every time its output buffer is full. You're writing a command to the keyboard controller, and the keyboard controller is placing the response in its output buffer.

Octocontrabass wrote: Why would a misaligned stack cause #UD?

Didn't know It won't. My thinking was the return address points to some garbage which will cause CPU to execute something bad and finally cause a UD exception. I'm safe as I'm in an emulator.

Octocontrabass wrote: The PS/2 keyboard controller (and its ancestor, the AT keyboard controller) raises an interrupt every time its output buffer is full. You're writing a command to the keyboard controller, and the keyboard controller is placing the response in its output buffer.

So that's how it's works... So It is Normal. So I should turn on sti after doing all this.

pranavappu007 wrote:One of the was UD exception. Now to test it, I initially tried to break stack alignment of my keyboard ISR, hoping that when I press a key after my OS has booted, the stack will misalign and UD Exception will be raised.

Yeah, that will not work. Next time, just execute the ud2 opcode. It is defined to be undefined.