Page 1 of 1
Interrupts again...
Posted: Sun Oct 17, 2004 9:37 am
by Triumph
Hi!
My PIC and IDT is almost finished now, and it seems to react fine on divide by zero and keyboard strokes...
But when the interrupt has finished, my OS just reboots. How can this be?
Code: Select all
[extern _KeyboardResponse]
[global _keyb_int]
_keyb_int:
pusha
push ds
push es
push fs
push gs
mov eax,0x10
mov ds,eax
mov es,eax
cld
in eax, 0x60
push eax
call _KeyboardResponse
add esp, 4
pop gs
pop fs
pop es
pop ds
popa
iret
Code: Select all
void KeyboardResponse(int key)
{
output(1, 1, "Test", GREY_TXT, true);
outb(MASTER1, EOI);
}
Re:Interrupts again...
Posted: Sun Oct 17, 2004 9:55 am
by Pype.Clicker
this typically occurs when you messes up the stack ... while IRET'ing, the processor finds an invalid segment somewhere and issues an exception.
If your exception processing code is not 100% up and running, you're heading straight towards a system reset (due to a triple fault)
Re:Interrupts again...
Posted: Sun Oct 17, 2004 10:12 am
by Triumph
Well, but i can't see anything wrong in my code
Could it be while loading IDT or remapping the PIC, the error occours?
Re:Interrupts again...
Posted: Mon Oct 18, 2004 2:36 am
by Pype.Clicker
i don't see any obvious error either... maybe running in a debugging-enabled bochs with "trace-on" will help ...
Re:Interrupts again...
Posted: Mon Oct 18, 2004 3:18 am
by Curufir
Well I do have one thought.
Which compiler are you using?
Some C function calling conventions actually expect the function being called to clear off the stack, not the caller. That would screw up the stack for you, and lead to the exception.
The other thing that's a little curious is you reading in a doubleword from port 0x60. The data register is only 1 byte in length, and ports 0x62/0x63 might not even exist on your system. I'm not sure what happens in that scenario (NMI?), but it can't be anything good.
Re:Interrupts again...
Posted: Mon Oct 18, 2004 5:13 am
by Pype.Clicker
i also know there were versions of NASM mishandling "iret" and "popa/pusha" in 32bits (e.g. not making them "iretd", "popad" and "pushad")... I'm not sure if that's what happening to you but i'd cross-check the bytes generated against the instructions reference as a last resort...
Re:Interrupts again...
Posted: Mon Oct 18, 2004 6:03 am
by Triumph
I'm using the gcc compiler, which comes with DJGPP, and it was a mistake to load from port 0x60 to EAX, meant to do it to al
However I can't get bochs debug to run my OS. It says something about context not implemented due to some hash map parameter = 0 :S
Re:Interrupts again...
Posted: Mon Oct 18, 2004 7:47 am
by Pype.Clicker
that should only be a warning, iirc.
don't you get a
Code: Select all
(0) [0x000ffff0] f000:fff0 (unk. ctxt): jmp f000:****
<bochs:1>
line at the end of the log ? if you do, type "trace-on" and then "c" to run...
note: to save hours of wait state, you can do a "break 0x7C00" "C" and enable "trace-on" only when the breakpoint is met
Re:Interrupts again...
Posted: Thu Oct 21, 2004 12:28 pm
by Triumph
Well, you're right that's what it says to me, but then how can i fix this error? It's pretty anoying, to get an triple fault every time an interrupt ocours...
Re:Interrupts again...
Posted: Fri Oct 22, 2004 2:34 am
by Pype.Clicker
i cannot tell just like that! Your code seems correct, but obviously either it isn't, or something else occurs (kernel not completely loaded, memory overwritten, or any other NastyBug)
One way to sort out what actually occurs is to request the emulator to produce a list of *every instruction* it performs. This way, you'll be able to check *what* is going wrong and *why* ...
If you can tell me what were the last few instructions that were performed before the triple fault occur, i could probably help better...
Otherwise, making sure that you catch and report exceptions (see the FAQ) can help figuring out what's wrong too, but it's usually harder than watching the trace.