Issues with interrupts

[Techflash]

Before I even start, I want to say that: Yes, I have read the GDT and IDT and "Why are my interrupts not working?" page on the Wiki. My code is hosted on https://github.com/techflashYT/Techflash-OS
It does not crash. It makes it to the inf loop at the end of the kernel, but nothing happens at all, neither the PIT interrupt, nor the keyboard works at all.

[Octocontrabass]

Where do you enable interrupts?

[Techflash]

Where do you enable interrupts?

I found the `sti` instruction in both ISRASM.S and IDTASM.S

[Octocontrabass]

In ISRASM the STI instruction occurs immediately before IRETQ, so it does nothing. Delete it.

In IDTASM the STI instruction occurs in the function IDTFlush. Where do you call IDTFlush?

[Techflash]

In ISRASM the STI instruction occurs immediately before IRETQ, so it does nothing. Delete it.

In IDTASM the STI instruction occurs in the function IDTFlush. Where do you call IDTFlush?

Crap, the file must not have saved right last time, hang on.

UPDATE: Fixed the broken IDT code, still doesn't work.

[Octocontrabass]

Where do you initialize the interrupt controller?

[Techflash]

Where do you initialize the interrupt controller?

I've heard that it doesn't need to be; GRUB already initializes it. If that's incorrect I can do that.

Also, wouldn't it triple fault if I tried to send commands to it before initialization?

[Octocontrabass]

Where on earth did you hear that? Neither Multiboot nor Multiboot2 mention anything about it.

[Techflash]

Where on earth did you hear that? Neither Multiboot nor Multiboot2 mention anything about it.

I don't remember anymore, it was a while ago.
UPDATE: Found a function on the Wiki for initializing the PIC, but I can't seem to find anywhere what parameters to call it with.

[Octocontrabass]

Found a function on the Wiki for initializing the PIC, but I can't seem to find anywhere what parameters to call it with.

If you're talking about the code on this page, it writes those values to the PICs during initialization. You can refer to the 8259A datasheet to see exactly how each 8259A will interpret those values.

[Techflash]

Found a function on the Wiki for initializing the PIC, but I can't seem to find anywhere what parameters to call it with.

If you're talking about the code on this page, it writes those values to the PICs during initialization. You can refer to the 8259A datasheet to see exactly how each 8259A will interpret those values.

Alright, I'll do that then, I need to take a break for a few hours though.

[Techflash]

UPDATE: It really seems like it's already being initialized somewhere... somehow. Not sure where in the code it is, but since I'm definitely already receiving interrupts, I think that the PIC is fine. But now after some tweaking to my IDT code, I'm getting this error in Bochs:

Code: Select all

06958696000e[CPU0  ] interrupt(long mode): must be 64 bit segment
06958696000e[CPU0  ] interrupt(long mode): must be 64 bit segment
06958696000e[CPU0  ] interrupt(long mode): must be 64 bit segment
(0).[6958696000] [0x000000113f30] 0008:ffffffffffe03f30 (unk. ctxt): test ecx, edx             ; 85d1
06958696000p[CPU0  ] >>PANIC<< exception(): 3rd (13) exception with no resolution

My code segment (0x08) according to Bochs is 64-bit:

Code: Select all

cs:0x0008, dh=0x00209900, dl=0x0000ffff, valid=1
        Code segment, base=0x00000000, limit=0x0000ffff, Execute-Only, Non-Conforming, Accessed, 64-bit

The only thing that I can think of is the IDT is messed up and it's reading some garbage data when it's trying to find where the CS to switch to is

[Octocontrabass]

UPDATE: It really seems like it's already being initialized somewhere... somehow.

It isn't. Your OS will fail to receive interrupts on some PCs because the interrupt controllers are not initialized.

But now after some tweaking to my IDT code,

It's hard to spot bugs in your code when I can't see the current version of your code.

The only thing that I can think of is the IDT is messed up and it's reading some garbage data when it's trying to find where the CS to switch to is

Perhaps. Try using "info idt" in the Bochs debugger.

[Techflash]

It isn't. Your OS will fail to receive interrupts on some PCs because the interrupt controllers are not initialized.

Hmm... I wouldn't have though that Bochs would init them by default but maybe.

It's hard to spot bugs in your code when I can't see the current version of your code.

The latest version of my code has been available at https://github.com/techflashYT/Techflash-OS since the beginning.

Perhaps. Try using "info idt" in the Bochs debugger.

Will try in a second.
Log of this is at: https://gist.github.com/techflashYT/3c5 ... 7f08cfffe7
Perhaps I should fill out the entire rest of the IDT with stub entries instead of just zeroes?

[nullplan]

Perhaps I should fill out the entire rest of the IDT with stub entries instead of just zeroes?

That is generally a good idea. Between IOAPIC, local APIC, and MSI, you can generally not know how many interrupts you will have ahead of time these days. Filling the entire IDT can be done as simply as:

Code: Select all

.align 8
.global external_interrupt
external_interrupt:
.set interrupt,32
.rept 256-32
  pushq interrupt-128
  jmpq interrupt_common
.align 8
.set interrupt, interrupt+1
.endr

This defines a new symbol, "external interrupt", that handles interrupt 32. You need to define your own function "interrupt_common". It is entered with an IRET frame and the interrupt number less 128 on the stack. The encoding is chosen such that for all possible values of "interrupt", the encoding of the push instruction is the short encoding. This means that all interrupt handlers are exactly 8 bytes apart from one another (you have 2 bytes for the push and at most 5 for the jump, makes 7 in total, aligned to . So now you can define in C:

Code: Select all

extern const char external_interrupt[];
for (int i = 0; i < 256-32; i++)
  set_idt_entry(i + 32, external_interrupt + 8 * i);

Your "interrupt_common" function will then need to save all registers, probably fix up the interrupt number on stack, then call whatever interrupt handler you need to. Then restore registers and do whatever work is required when returning from interrupt.