interrupt problem

[beyondsociety]

I originally had interrupts working in assembly and decided to switch the loading of my exception and interrupt handlers to c and now its tripple faulting when I enable interrupts. If a generate a asm("int $0x20") for an interrupt and asm("int $0") for a exception, its works so I know my interrupt and exception handlers are setup right.

I also tried disabling all my exception handlers, masking all interrupts, initializing the timer, and unmasking the timer interrupt, but it tripple faults when I enable interrupts.

Any suggestions?

[beyondsociety]

I did a memory map of the code but the EIP address thats tripple faulting isnt in the table. I wonder if disassembling the code using objdump would help to solve my problem, its worth a shot.

I also have some other ideas that Im going to try and I'll post my results later.

[beyondsociety]

After doing some testing, I have come to the conculsion that my main problem is with my install handler code. I was using the code from flick os, but since its not working I going to look at a few other os's and see if there ideas work, if not Im going back to asm.

I'll keep you posted on my results.

[nullify]

A) Try installing exception handlers, masking all IRQ's, and enabling interrupts. Does that still yield a triple fault?

B) I think it would be helpful if you could show the code you are using for interrupts, IDT, PIC, etc.

C) I have working IDT code done in C, but its probably better to see if you can fix what you already have instead of just throwing your existing code out the window for mine. If it proves too difficult a bug to identify, I'll post my code here.

[Pype.Clicker]

if using bochs, consider checking your IDT setup with a dump_cpu command :p and your interrupt handlers setup by inspecting memory content at IDTR.base with x command

[beyondsociety]

A) Try installing exception handlers, masking all IRQ's, and enabling interrupts. Does that still yield a triple fault?

B) I think it would be helpful if you could show the code you are using for interrupts, IDT, PIC, etc.

A) Works fine on bochs. On real hardware it tripple faults when it gets to the loading of the exception handlers.

B)Code attached. For simplicity I have included the necessary code to diagnose my problem into two files. The code will not work if you try to compile it.

if using bochs, consider checking your IDT setup with a dump_cpu command :p and your interrupt handlers setup by inspecting memory content at IDTR.base with x command

How would I do this?

[attachment deleted by admin]

[Pype.Clicker]

A) Works fine on bochs. On real hardware it tripple faults when it gets to the loading of the exception handlers.
%rep 256
dw 0x0000 ; Offset 15:0
dw K_CodeSel ; Selector
db 0x0000 ; (Always 0 for interrupt gates)
db 0x8e00 ; Present,ring 0,'386 interrupt gate
dw 0x0000 ; Offset 31:16
%endrep

i'm unsure how your assembler handle this, but imho, 0x8e00 is too large for a byte constant ...

Code: Select all

   mov ebp, esp
   mov ebx, [ss:ebp + 20]          ; Interrupt number
   mov eax, [ss:ebp + 24]          ; Interrupt handler
   mov edx, idt                  ; Idt location

i would rather suggest you to push ebp; mov evp,esp as the very first instruction of a function that deals with C-provided parameters. Using things like ebp+20 for the first item introduce errors risks when you'll push more things on the stack at function startup ...

Code: Select all

   install_handler(0,  (void*) &ISR0,  0x8E00); // Divide Error

installs the C function, not the assembler stub ...

if using bochs, consider checking your IDT setup with a dump_cpu command :p and your interrupt handlers setup by inspecting memory content at IDTR.base with x command

How would I do this?

you need to compile bochs with ./configure --enable-debugger or something alike ... then you'll get a prompt when your virtual CPU tries to execute the first instruction.

http://www.cs.umd.edu/~hollings/cs412/s02/debugger.html for more info