OSDev.org

Hi. I just started looking into OS development a couple weeks ago. I'd been toying with OSD for a while but then moved on to the SigOPS DemOS because I thought the code/libc was much cleaner. Anyway, I've been trying to get interrupts to work. I noticed with DemOS there are no ASM files, I think it's all generated in their bootmaker program... And so all the ASM I need to do has to be inline. I've read about 30 pages of this forum and at least 3-4 tutorials on IDT and remapping the PICs, but I still can't get it to work. Sometimes (after I remap the PICs) when I do asm("sti");, the machine will reboot. Othertimes when I try to unmask the IRQs, it will reboot.

Is anyone familiar with DemOS? It already handles exceptions, and has the ASM for interrupts, but it's not documented at all and I'm having no luck getting it to work.

Okay, there was a bug in the code that was causing the reboots. But now when I try to remap the PICs, I always get a Divide by Zero exception.



That's in the main body of the kernel. I'm not sure if the remapping should be before or after the exceptions are initialized... I tried it both ways with the exact same results.



If I comment out the asm("sti"); or the enable_irq(1); in this function, I do not get the Div/0 exception. But it also probably silently breaks it.



Does anyone see anything wrong with this? I think it's all correct, but I don't know what else could be causing it.

you suffer the same ICW4 error as somebody else on this thread

I don't know if that helps me or not.

Here's what it's doing now:

1) I initialize the IDT
At this point, exceptions work. Doing a 1/0 in the code will trigger the Div/0 exception on purpose.

2) I remap the PICs.
I have no idea if the PICs -really- get remapped. Can I tell? The code is up there, though. It looks about the same as every tutorial I've read.

3) I enable the IRQs with enable_irq(0xFC)

4) I do: asm("sti");
As soon as I do this, I immediately get a Div/0 error. I am not certain, but I think it -might- be the timer though. Maybe the remap didn't work? Because if I send EOI back to the Div/0 exception, it keeps doing it over and over endlessly. If I cli, the exception will only execute once.

In the code, if I do an "int 0", it will trigger my Div/0 functions. If I do an "int 20", it will trigger my timer function. I guess that means my IDT works, but why won't the machine automatically call my routines? My timer never fires unless I manually trigger it.

indeed, it seems you're messed up things in the PIC remapping function.

here's the code i use ...

I translated that into C and plugged it into my code and now when I asm("sti"); it immediately triggers a general protection fault as opposed to the Div/0 exception. I wonder which one's worse. ::)

Any more ideas? With that pic remapping function, doing a 1/0 in the code still triggers exception 0 (Good, I think.), and the GPF loops forever if I respond with EOI (I'm not sure if that's desired behavior or not.)

i guess we have progressed, because if there's something wrong with your interrupt code before the "print" command is issued, then it will actually issue a GPF.
Now, i think you should try to see *where* the GPF comes from (i.e. look at the stack and try to get the value of eip, or if you're using bochs try to enable calls trace through the debug interface).

either the GPF comes from your "normal code", which may mean the IRQ0 is actually mapped to INT0xD, but i don't think that's the case, or the GPF has been produced by your interrupt handler -- in which case you'll have to debug that handler.

A last option is that the GPF is generated by the maincode because your ISR returns an unexpected state, but in that case, you should see the 'timer output'.

Remember there are rules for the hardware ISR, such as they must be at code level 0, etc. if you break those rules, you'll get a GPF with the interrupt number as the error code.

Also try to get the error code (pushed on the stack) of your GPF, so that you know what's the item that goes bad.

Thanks for all your help thus far.

Okay: So. I'm not using bochs, but I do have a debug routine that will dump all the registers. Here's what it looks like:

General Protection Exception:
EIP: 0x00100183 CS: 0x00000008 EFLAGS: 0x00010246 errcode: 0x00101165
eax: 0x00000101 ebx: 0x00101080 ecx: 0x0000000e edx: 0x000003d5
esi: 0x0000a400 edi: 0x00000010 esp: 0x0000ffc0 ebp: 0x0000ffe8

I tried mapping the IRQs to different addresses and the GPF still happened, so I think that rules out being mapped to INT0xD.

I was looking this up on google and some page said that if my CPL is less than the IOPL, executing cli/sti/out/in would cause an INT0xD... Could this be the case? How could I check/fix it?

you can see your EIP where it happens, so you should be able to disassembler your kernel wou will know what routine triggered the fault.. unless tyhe EIP printed is not the EIP of the fault...

the other thing i should add, is, have you dummy handlers for your interrupts? eg: plain IRETs for clock etc, since they will trigger as soon as you enable interrupts.

I'm using linux and I have only used ndisasm, which didn't provide very much use to me. Although, I'm not too familiar with it, I might not have been using it correctly here.

The dummy handlers are set up correctly, but I don't believe they are getting called at all because none of the printfs inside of them are executing.

if you have linux, you can try objdump -x to get information about your symbol map. Also try to ask the linker generating that symbol map for you (ld -Map <mapfile>).

if you have a "-g" version of your kernel, also try objdump -dlS to get a line-number dissassembly which interleaves C source lines and disassembled instructions.

However, by the look at your error code, i would say some "pop segment" have gone wrong, or something alike.

The debugging continues...

I ripped out the IDT (which basically just consisted of C macros and inline assembly) and made a new one in asm. That seemed to fix some things... I'm not getting the GPF when I asm("sti"); in my kernel anymore, but as soon as I hit a key on the keyboard, I get an exception 13. Not sure what could be causing that yet either, since ripping out the old IDT broke the register dump.