Can't get interrupts working

[io12]

Both hardware and software interrupts are not getting called. I can call them manually, so it may be an IDT problem? The information at http://wiki.osdev.org/I_Can%27t_Get_Interrupts_Working wasn't very helpful.

My code is at https://github.com/io12/OS.

Can anyone please tell me what the problem is?

[eryjus]

I may have missed it, but I do not see where you are initializing your PIC and masking the IRQs you want to receive.

Also, please see http://wiki.osdev.org/James_Molloy%27s_Known_Bugs

[io12]

The PIC is initialized at src/cpu/idt.c:106. I did forget to mask the interrupt for the timer, but it's added now at src/drivers/timer.c:16. For some reason, https://github.com/rhtyd/tantra seems to work without masking interrupts. Anyway, the timer still doesn't work and now I get a triple fault on keyboard input.

[Combuster]

Make sure you collected enough information about your own situation (for instance running your code in Bochs).

So you say you read it. Where's the bochs log?

[io12]

My bochs log is here: http://ix.io/SGZ

Here are some parts that seem important:

Code: Select all

04581254540e[CPU0  ] interrupt(): gate descriptor is not valid sys seg (vector=0x06)
04581254540e[CPU0  ] interrupt(): gate descriptor is not valid sys seg (vector=0x0d)
04581254540e[CPU0  ] interrupt(): gate descriptor is not valid sys seg (vector=0x08)
...
04581254540e[CPU0  ] exception(): 3rd (13) exception with no resolution, shutdown status is 00h, resetting

I recognize the the last line as a triple fault. The first three probably refer to the GDT or IDT, but I checked both of them many times and they seem fine.

EDIT: I increased the size of the stack. Now the top three lines changed to:

Code: Select all

04480420992e[CPU0  ] interrupt(): not accessible or not code segment cs=0x0008
04480420992e[CPU0  ] interrupt(): not accessible or not code segment cs=0x0008
04480420992e[CPU0  ] interrupt(): not accessible or not code segment cs=0x0008

[Combuster]

they seem fine

Some huge mistakes here:
- You state a guess. You should never guess things when debugging a problem.
- It literally says "descriptor is not valid". Therefore your statement that the GDT/IDT is fine is an outright fabrication.

As far as guessing goes, the information regarding your real issue shows up quite nicely amongst the things you guessed to be not important. Have you really checked everything against what you intended your code to do?

[io12]

Can you please tell me what the problem is? I really need help here.

[eryjus]

Can you please tell me what the problem is? I really need help here.

In the interest in helping you become self sufficient... Find the line in the log that says

Booting from 07c0:0000

The PC is booting.

Then read the next line.

Now you come to the other lines you called out as important...

interrupt(): gate descriptor is not valid sys seg (vector=0x06)
interrupt(): gate descriptor is not valid sys seg (vector=0x0d)
interrupt(): gate descriptor is not valid sys seg (vector=0x08)

You are right, they are important. They are even more important in the context of the line you skipped.

Hints:
[*] What is an interrupt 0x06?
[*] What is an interrupt 0x0d?
[*] What is an interrupt 0x08?

If you still need a hint, See Here

Then, after that you get a triple fault and a CPU status dump, but you knew that already.

[io12]

I found the problem. My idt_set_gate function overwrote base_low. Thanks for the help. I wonder why I didn't notice the problem earlier. I found the problem when running the bochs debugger when I noticed int 0x0 jump to 0x00000010. I then checked the IDT and found that every base was 16. I steped through the code on gdb and was able to find the problem.

[Combuster]

Good job on finding it mostly on your own

I wonder why I didn't notice the problem earlier.

Debugging is a state of mind, and it requires care and precision. Typical emotions such as frustration have the opposite effect, so you'll need to practice letting go of that and work accurately instead. If you ever heard of the term "Guru meditation", you might realise why it's an appropriate alternative term.