Page 1 of 1
interrupt issues
Posted: Thu Jul 19, 2007 2:37 am
by spectrum
hi all,
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:
Code: Select all
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".
If any help,
many thanks, angelo
Posted: Thu Jul 19, 2007 3:31 am
by spectrum
'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:
Code: Select all
00015821584i[CPU0 ] BxError: instruction with opcode=0xff
00015821584i[CPU0 ] mod was c0, nnn was 7, rm was 7
00015821584i[CPU0 ] WARNING: Encountered an unknown instruction (signalling illegal instruction)
00015821584d[CPU0 ] UndefinedOpcode: ff causes exception 6
00015821584d[CPU0 ] exception(0x06)
00015821584d[CPU0 ] interrupt(): vector = 6, INT = 0, EXT = 1
00015821584d[CPU0 ] int_trap_gate286(): INTERRUPT TO SAME PRIVILEGE
thanks,
angelo
Posted: Thu Jul 19, 2007 4:15 am
by jnc100
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.
Regards,
John.
Posted: Thu Jul 19, 2007 5:22 am
by AJ
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
Cheers,
Adam
Posted: Thu Jul 19, 2007 6:54 am
by spectrum
many thanks all,
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.
Infinite thanks again,
angelo