Not working on real hardware...

[petrusss]

I've just fixed so IRQ's work in Bochs in my OS, but then I tested on another computer with a floppy: The IRQ was fired (keyboard), and my function was called (printed out a char on the screen), and then I got some General Protection Faults until the computer rebooted.
Why is this?

[Pype.Clicker]

hard to say ... it may come from differences on the load process (for instance, BOCHS never encounter bad sector nor reading problems, while a typical FDC may require up to 3 call to INT13 before it can actually read the sector correctly) you'll have to collect more information about the crash location (register values, code position and maybe stack content) before we can understand better what's happening...

[Neo]

another important thing is that BOCHS almost always gives you clear memory but you dont get that in a PC. this was a nasty bug for me as i have only 1 PC for testing as well as writing code. HTH

[petrusss]

Okey!
I solved the problem by not pushing and poping ds, es, fs and gs before and after the call to my function in my ISR stub.

[Pype.Clicker]

that's not an option! if the IRQ occurs while you were working on some other copies of ds,fs,gs,es (including user level code interrupted), you'll HAVE to save segment registers and set system segment registers if you want the ISR to run properly.

You wouldn't dare to call a "kprint" function with DS == user-level segment, would you ??

[petrusss]

But then, why does it crash when I push those registers?

[Jamethiel]

A better question might be, "why does it crash when I pop those registers?"

I'd doublecheck the GDT, the initial values for all segment selectors, and that the stack is being set up properly.

[Pype.Clicker]

But then, why does it crash when I push those registers?

hard to tell, of course ... the 'push/pop' instructions may be the droplet that makes your kernel become one page larger for the linker, or maybe you're now overflowing the very-small BIOS-featured initial stack ...

until you are sure that your kernel is *properly* loaded by the real machine and that you can display reliable information about exceptions, debugging your kernel on real hardware will remain a nightmare ... and doing it without knowing every little bit of your stuff will remain impossible.

sorry.

[petrusss]

I've done some debugging:
FS is 0xEADB and GS is 0xF000 when the kernel starts on a real computer, but in bochs they're 0x0.

So, I did like this before the call to the kernel:

push 0x0
push 0x0
pop fs
pop gs

And now it works.

[Pype.Clicker]

yep. That's quite normal.
In a general way, you should have reset all the segment registers to correct values (i.e. selectors that exists in your GDT) just after you entered protected mode ...