[Solved] Kernel panic caused by IRQs or ISRs, please help.

[psimonson1988]

Hey again, in need of some help here goes. I've tried several things including rewriting the ISRs in C and they still don't work. So I changed them back to what I had before C/ASM. Not really sure what the problem is but I've done quite a bit of research and even searched and I haven't found anything relating to my issue, at least not my exact issue. Anyways, I would very much appreciate it if someone could look over it and let me know if I did something wrong when I implemented the IDT, ISRs and IRQs.

My project: boot32-barebones

NOTE: The files that deal with the issue are all located inside the kernel/cpu folder. Restructured my directory tree it was getting to be a nightmare.

Thanks in advance,
Phil

[nexos]

I haven't found the problem, but one small note. You say you will not put a license on it. When a product is unlicensed, that means no one but yourself can use it! It is probably a good idea to say instead "this product has been released to the public domain". Also, explicitly state there is no warranty. If you don't, someone could legally sue if it broken their computer. Will try to find IRQ problem. What causes the problem to occur?

[psimonson1988]

Thanks for the legal tip and I will probably add either MIT or release it to Public Domain. Since now I know I pretty much have to put a license on it for anyone else to use. To answer your question, just uncomment the line that is disabled on purpose in the kernel (kernel/kernel.c).

kernel/kernel.c:

Code: Select all

/*
 * kernel.c - Source file for kernel, main operation source code.
 *
 * Author: Philip R. Simonson
 * Date  : 06/27/2020
 *
 ***********************************************************************
 */

#include "isr.h"
#include "vga.h"
#include "io.h"
#include "helper.h"

/* Entry point for kernel.
 */
void kernel_main(void)
{
	// Initialize the terminal and install ISRs.
	term_init(BLUE, YELLOW);
	isr_install();

	// Disabled for now, because there is a problem with the ISR handlers.
//	irq_install(); // <-- uncomment this to see the problem...

	// Display welcome message to user and prompt.
	print("Welcome to my bare bones example 32 bit operating system.\n");
	print("\n  I have designed this because I would like to teach beginners\n");
	print("the proper way of doing things. As far as a beginning operating\n");
	print("system goes. Please feel free to clone and use it. If you are\n");
	print("are worried about a LICENSE don't be. I will NOT put a LICENSE\n");
	print("on this project. Also this software comes WITHOUT ANY WARRANTY\n");
	print("of any kind. I will not be held accountable for any damage this\n");
	print("software may cause. Please use at your own risk.\n");
	print("\n\nCheers,\nPhilip R. Simonson (aka 5n4k3)\n\n");
	print("Welcome to a bare bones kernel! This is a temporary shell.\n");
	print("Please type 'help' to see what you can do.\n\n> ");
}
/* Kernel process user input.
 */
void user_input(char *input)
{
	if(!strcmp(input, "EXIT")) {
		print("Halting CPU...\n");
		__asm__ __volatile("hlt");
	} else {
		print("Invalid command entered. Try 'help'\nto see what you can do.\n");
		print("> ");
	}
}

[nexos]

The problem is in set_idt. You use lgdt, not lidt. I changed that, and it fixed the problem. Also, you should send EOI after calling the IRQ handler. That way, your interrupt handler won't get interrupted by another hardware IRQ.

[psimonson1988]

Thanks for pointing out that I was trying to replace the current GDT with an IDT. Wow typos get the best of us don't they? Anyways, what do you mean by EOI? How and where do I put that?

[Minoto]

Anyways, what do you mean by EOI? How and where do I put that?

https://wiki.osdev.org/index.php?title= ... =EOI&go=Go

[Octocontrabass]

Anyways, what do you mean by EOI? How and where do I put that?

End of Interrupt. You can find more details in the wiki and in the 8259A datasheet.

Typically, you want a higher-priority IRQ to interrupt a lower-priority IRQ, but not the other way around. The PIC keeps track of which IRQs it has raised, so it won't try to raise a lower-priority IRQ until you send EOI to acknowledge that you've completed handling the high-priority IRQ. If you send the EOI before you run the handler, the PIC thinks you're done and it can raise a low-priority IRQ.

In the same vein, you typically don't want to receive another of the same IRQ until after you've finished handling it. The PIC won't send the same IRQ until after it receives an EOI, so if you send EOI before you're done handling the IRQ, your IRQ handler might get interrupted by itself. This is especially a problem with level-triggered IRQs, which are used for IRQ sharing. In modern hardware, some IRQs are level-triggered even if you program the PIC for edge-triggered IRQs.

And speaking of programming the PIC, you must mask IRQs you aren't prepared to handle yet. For edge-triggered IRQs, you might send an EOI before the handler can acknowledge the hardware, and you'll stop receiving IRQs. For level-triggered IRQs, you'll receive an IRQ flood from not acknowledging the hardware!

Unrelated, but you should remove the STI you've placed right before IRET. IRET pops EFLAGS off the stack, so there's no sense in trying to update IF right before another instruction that will modify IF. (If you want your IRQ handler to start with interrupts disabled, use an interrupt gate; otherwise, use a trap gate. The only difference between the two is that an interrupt gate clears IF after it pushes EFLAGS onto the stack.)

[8infy]

In the same vein, you typically don't want to receive another of the same IRQ until after you've finished handling it. The PIC won't send the same IRQ until after it receives an EOI, so if you send EOI before you're done handling the IRQ, your IRQ handler might get interrupted by itself. This is especially a problem with level-triggered IRQs, which are used for IRQ sharing. In modern hardware, some IRQs are level-triggered even if you program the PIC for edge-triggered IRQs.

But usually people use interrupt gates for IRQs so sending an early EOI shouldn't be an issue right? What happens if u send an EOI with interrupts disabled and PIC wants to send the same interrupt again? Will it get delivered upon IRET (and thus reenabling interrupts)?

[Octocontrabass]

But usually people use interrupt gates for IRQs so sending an early EOI shouldn't be an issue right?

As long as you never enable interrupts in your IRQ handler, that's true. But you may decide that you'd rather spend some stack space to get better IRQ latency and enable interrupts (either by switching to a trap gate or by using STI), and then it will be a problem.

What happens if u send an EOI with interrupts disabled and PIC wants to send the same interrupt again? Will it get delivered upon IRET (and thus reenabling interrupts)?

It will be delivered when you re-enable interrupts. If you use an interrupt gate without STI, it will be delivered after IRET.