Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
i have some troubles when IRQ0 happen. To handle interrupts, I've used the same routine as in Bran's kernel tutorial,
but if inside the irq0 specific routine i try to print something out on the screen, i get:
00001106940d[CPU0 ] interrupt(): vector = 32, INT = 0, EXT = 1
00001106940d[CPU0 ] int_trap_gate286(): INTERRUPT TO SAME PRIVILEGE
00001106988e[CPU0 ] write_virtual_checks(): no write access to seg
00001106988d[CPU0 ] exception(0x0D)
00001106988d[CPU0 ] interrupt(): vector = 13, INT = 0, EXT = 1
after a while bochs reset.
If i comment the call to "kprintf" inside the custom irq handling routine, i don't get the triple fault exception anymore, but after some seconds, i get "invalid opcode exception".
've soloved one of the problems: inside the general irq handler, i was setting up a code GDT entry, instade of a data one. Now i can print messages on the screen from the interrupt routine.
Now remain the problem that after some seconds i'm in a for ( ; ; ) ; i get invalid opcode exception:
What values are you using in your idt? If you're using trap gates, rather than interrupt gates, and don't do a cli, then your interrupt handler can be interrupted by another interrupt. I'm guessing a little while into your for(;; ) loop (which really shouldn't generate an invalid opcode) the timer interrupt is firing and somewhere you mess up the stack and corrupt the return eip and make it point to an invalid opcode.
For debugging, I suggest you note the invalid opcode EIP and then do an objdump to get the location of the faulting address inside your kernel. You will then be able to confirm jnc100's diagnosis
yes, sure, the problem was my bad code. As you said, there was a stack misalignment (add $4, %esp) that i had removed from the little "c library" that i use to call kernel isr. I've removed it but not recompiled or reinstalled properly, so even if i was searching the problem in the kernel, it was always persistent.