Interupts work in QEMU but not real hardware

[dannywrayuk]

After solving some issues I had with VGA fonts I needed some text to print to the screen.
I decided to start work on an interrupt handler so I could get keyboard events. I managed it relatively easy. setting up the IDT entry and stuff.
It works great.. in QEMU.
When I burn the OS to a usb and run it on real hardware it breaks. The OS loads pretty much everything, but then when trying to load_IDT it reboots. I assume its triple faulting?
I managed to narrow down the issue by commenting out sections and trial and error. The exact point that the OS crashes is on the call of STI in the load_IDT function:

Code: Select all

global load_idt
load_idt:
	mov edx, [esp + 4]
	lidt [edx]
	sti   ; HERE
	ret

I'm not sure what the problem is, why would it run perfectly on QEMU but not real hardware? The laptop I used to test has an AMD processor but I doubt it could be that?
Here is the link to my github: https://github.com/dannywrayuk/DanOS , check kernel.asm and IDT.h

[Octocontrabass]

Why is all of your code in header files? That's not how C++ is designed to work.

In order to debug on hardware, you should add exception handlers to give you more information about the crash, instead of causing a triple-fault and rebooting.

Your keyboard_handler function is not following the ABI correctly: it calls a C function without first preserving registers that must be saved across function calls. (I'm not sure if this is the cause of your crash, but fixing it now will save you time debugging later.)

[dannywrayuk]

Yeah I'm aware. Are the actually any downsides to keeping code in header files though? because it certainly makes linking files etc easier.

To turn on interrupts would I also not have the same problem? or to enable them do I not need to all sti? - I'll give it a go.

and yeah i know I removed it while trying to figure out the cause o f the crash.

[Octocontrabass]

Yeah I'm aware. Are the actually any downsides to keeping code in header files though? because it certainly makes linking files etc easier.

The biggest downside is that you won't get much help because your code is difficult to navigate. Elsewhere on this forum there's a good post that explains the other downsides, but I don't have a link handy at the moment.

To turn on interrupts would I also not have the same problem? or to enable them do I not need to all sti? - I'll give it a go.

Exceptions can occur regardless of whether interrupts are enabled or disabled. You can use your exception handlers to display information about the CPU state when your OS crashes, instead of rebooting. With the right information, it should be possible to spot the bug.

[dannywrayuk]

I'm a little confused, if I can't map the idt how can I handle the exception? Everywhere I look exceptions and interrupts are dealt with in the same way - mapping the idt to a function handler.
My error occurs when I'm trying to set up the idt. How can I implement expetion handlers to debug, if the thing I'm trying to debug is setting up the handlers! Seems a little circular ahah.
Again my problem isn't that they dont work, they do in qemu, just bot in real hardware.

[kzinti]

What kind of exceptions are you talking about? There might be some confusion here between hardware exceptions (interrupts/errors) and software exceptions (C++) that have nothing to do with interrupts.

[Octocontrabass]

I'm a little confused, if I can't map the idt how can I handle the exception?

How do you know this is the problem? Personally, I suspect you're receiving an IRQ that you didn't set up a handler for. If you set up exception handlers, you'll see this reflected in the CPU state when your kernel crashes.

What kind of exceptions are you talking about?

Hardware exceptions.