[Deleted] Importance of interrupts(Generic question)

[kzinti]

Is there a reason you can't read the wiki and Intel's manuals?

[iansjack]

If a particular interrupt can occur then you need a handler for it. Just define a generic routine that halts the processor, ignores the interrupt, or prints an error message. Use this for all interrupts that don't have specific handlers.

The IDT only needs to be as long as the highest used entry. So, if your highest interrupt is 80 make it 80 entries long.

[pranavappu007]

I was trying to implement inerrupts in my test bootloader. Hell broke loose, but I finally managed to catch exceptions by CPU. Thank god I can actually find out in case of a crash as I will not crash the CPU but run my code.

Then I set PIC to offset IRQs by 0x20 and 0x28. Then worte an interrupt handler to the keyboard which just reads and displays key(so that I know it worked).

Finally, tried to turn on using sti and behold! Prints message from my common routine for interrupts, meaning some exception has occured. Took my time and found out which one, the 15th int or Page Fault.

So I should implement paging to enable interrupt? I couldn't even believe how i made out with segmentation, let alone this IDT. What is happening?

Edit: These exception things are actually very useful to find out previously unknown random crashes, so even if this failed, I am planning to implement an exception only IDT inorder to preven crashing and make debugging faster.

[iansjack]

If you haven't enabled paging then you won't be getting page fault exceptions. You don't need paging for interrupts to work. (But you'll want to use paging eventually, so it's a good idea to learn about it.)

Exception 15 is "reserved" so there's something wrong with the way you are determining which exception has occured.

[pranavappu007]

If you haven't enabled paging then you won't be getting page fault exceptions. You don't need paging for interrupts to work.

I am quite sure I haven't enabled paging. I use segmentation by default and even that is just a flat overlapping segment as I don't have any "untrusted binary code" to execute. Does that mean paging might be on by default?That should crash the CPU at the first place, right? I tried not giving cli in the first place, and that turned out to be a double fault. Seems I have to use cli, and the sti can be used only after setting up all the segment register to get the less serious exception.

Maybe I miscounted and if it is a GPF? Or that reserved 16th int? Does it make sense then?

As I said, my entire kernel and bootloader is in ring 00, so shouldn't be a GPF. If my IDT is wrong, how come it catch the exceptions correctly?

[bzt]

Hi,

please listen to @kzinti, read the manuals and the wiki. All your questions are answered there.

Then I set PIC to offset IRQs by 0x20 and 0x28.

There are 16 IRQ lines not 8, but IRQ2 will never trigger an ISR (that's for cascading IRQs 8-15). Shouldn't be an issue at the moment, just saying.

Maybe I miscounted and if it is a GPF? Or that reserved 16th int? Does it make sense then?

There's no such thing, miscounting. You must know for sure. Try "bochs" or "qemu -d int", both should print out when an interrupt/exception happens, and which one.

As I said, my entire kernel and bootloader is in ring 00, so shouldn't be a GPF.

There are many reasons for a GPF. Read the manuals. AMD64 manual is easier to understand (good for reading), the Intel manual is more technical (easier to use when you know what you're looking for). In the instruction table, each instruction has a list of which exceptions it might raise and why. GPF is a jolly joker, used every time when no other exception fits the error.

If my IDT is wrong, how come it catch the exceptions correctly?

It is surely wrong, you're getting double faults. BTW it could be that the first 32 entries in the IDT are correct, and the rest aren't. It also could be that all entries are correct except for the keyboard IRQ. Also using trap gates instead of interrupt gates in the IDT is a pretty common mistake among beginners (but that causes trouble when you're trying to return from the ISR).

You could also test your IDT code with the "int" instruction. There are three kinds of interrupts:

• generated by the CPU on error, these are called traps, faults or exceptions. They should place the faulting instruction pointer on the stack
• hardware interrupts (IRQ), these are generated by the interrupt controller, the next instruction should be on the stack, and you must acknowledge the IRQ in the PIC
• software interrupts, generated by the "int" instruction, the next instruction should be on the stack, and no PIC invovled, no ack needed

In a nutshell, when a device (keyboard, disks etc.) wants the CPU's attention, it tells that to the PIC. The PIC then issues an "int" instruction, which will make the CPU to look up IDT and execute the ISR specified there. You could issue those "int"s yourself for debugging, without involving the PIC.

Cheers,
bzt

[pranavappu007]

[Deleted message]

[Octocontrabass]

I was trying to implement inerrupts in my test bootloader.

Before or after you switch to 32-bit protected mode?