Interrupts again...

[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);
}

[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)

[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?

[Pype.Clicker]

i don't see any obvious error either... maybe running in a debugging-enabled bochs with "trace-on" will help ...

[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.

[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...

[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

[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

[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...

[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.