[Solved] IRQ Firing Bug

[BrightLight]

Any time you see repeated three stacked horizontal lines followed by an S, you are printing your 16-bit Interrupt Table to the screen. This is likely because you are passing a null to a draw string function, so it is drawing everything from RAM address zero until it finds a null value.

Which is why we use paging to prevent this.

[Octacone]

Your drawstring function probably draws a string but your passing single characters to it which simply wont work.
Either code a proper printf function and you can use

Code: Select all

printf("%c", kbdus[keycode]);

or you find another solution.

Damn, that is not good.
How my PrintString functions works:
1. PrintString gets called: PrintString("abc123");
2. PrintString has a loop, foreach char inside that loop it calls another function called PrintCharacter.
3. PrintCharacter prints given char with wanted color using 0xB8000

[Octacone]

Should I use SendEOI Inside my kbd and timer handlers?

Yes. You should notify the master PIC any time it signals an IRQ (0-7), and notify both the master and slave PIC when the slave PIC signals an IRQ (8-15). Any IRQs that you have unmasked should have valid interrupt handlers that will notify the proper PICs installed before you unmask them.

When I enable while(1) loop I can use my timer and my keyboard. But I get these weird glyphs:

Any time you see repeated three stacked horizontal lines followed by an S, you are printing your 16-bit Interrupt Table to the screen. This is likely because you are passing a null to a draw string function, so it is drawing everything from RAM address zero until it finds a null value.

That's my guess.

(I get this a lot, by the way.. )

I see you get this a lot. You seem to be interrupts expert.

Hmm, about that slave master EOI sending etc, I already have that function inside my IRQ_Handler that does the same exact thing, to just copy paste it inside my Keyboard_Handler and Timer_Handler?

What do you mean by it prints 16bit interrupt table? I don't think so, because it prints only what I tell it to print. Little bit confused in there. Drawing from RAM??? I don't have any kind of memory management set up and I don't interact with RAM as fair as I know, or maybe I do?

[Octacone]

Any time you see repeated three stacked horizontal lines followed by an S, you are printing your 16-bit Interrupt Table to the screen. This is likely because you are passing a null to a draw string function, so it is drawing everything from RAM address zero until it finds a null value.

Which is why we use paging to prevent this.

It is sad that I still don't have any kind of memory management. Paging is my next big thing on the list.
Also I already know that: string paging; paging = "hell".

[BrightLight]

It is sad that I still don't have any kind of memory management. Paging is my next big thing on the list.
Also I already know that: string paging; paging = "hell".

Paging is actually very easy; but beginners to it seem to think it's difficult and I thought so myself.

[SpyderTL]

Hmm, about that slave master EOI sending etc, I already have that function inside my IRQ_Handler that does the same exact thing, to just copy paste it inside my Keyboard_Handler and Timer_Handler?

What do you mean by it prints 16bit interrupt table? I don't think so, because it prints only what I tell it to print. Little bit confused in there. Drawing from RAM??? I don't have any kind of memory management set up and I don't interact with RAM as fair as I know, or maybe I do?

What I meant to say is that whenever I see that pattern on the screen, with three horizontal lines and an S, it looks like what you would see if you copied the bytes starting at RAM address zero to the screen.

RAM address 0000:0000 is where the interrupt handler table is located when the machine first boots. My guess is that you are (accidentally) passing the wrong address to your print string function, and from the looks of the screen, I'm guessing that your print string function is attempting to draw whatever string is sitting at memory address zero.

Maybe that is a hint to help you track down the actual problem, but I could be wrong.

Hmm, about that slave master EOI sending etc, I already have that function inside my IRQ_Handler that does the same exact thing, to just copy paste it inside my Keyboard_Handler and Timer_Handler?

No, you only have to send the EOI once per interrupt (for each PIC, of course). Your original code looks like you were sending it twice per interrupt. I'm assuming that's fixed now.

[onlyonemac]

What I meant to say is that whenever I see that pattern on the screen, with three horizontal lines and an S, it looks like what you would see if you copied the bytes starting at RAM address zero to the screen.

Oh, so that's why I always get an S when I pass a NULL pointer to a string output function in my kernel, I never realised that. Not that it's a problem, just fascinating.

[Octacone]

What I meant to say is that whenever I see that pattern on the screen, with three horizontal lines and an S, it looks like what you would see if you copied the bytes starting at RAM address zero to the screen.

Oh, so that's why I always get an S when I pass a NULL pointer to a string output function in my kernel, I never realised that. Not that it's a problem, just fascinating.

lol, never tried printing an empty string. fascinating yeah

[SpyderTL]

There is a difference between passing a null address and passing an address to an empty string. If I had to guess, I'd say that your code is passing a null address.

[Octacone]

There is a difference between passing a null address and passing an address to an empty string. If I had to guess, I'd say that your code is passing a null address.

No worries, I fixed it.
For all future generations reading this: don't be stupid like me and instead of PrintStringFunction use PrintCharacterFunction and everything should be just fine.

[Ch4ozz]

There is a difference between passing a null address and passing an address to an empty string. If I had to guess, I'd say that your code is passing a null address.

No worries, I fixed it.
For all future generations reading this: don't be stupid like me and instead of PrintStringFunction use PrintCharacterFunction and everything should be just fine.

Thats what I told you before didnt I?

[Octacone]

It is sad that I still don't have any kind of memory management. Paging is my next big thing on the list.
Also I already know that: string paging; paging = "hell".

Paging is actually very easy; but beginners to it seem to think it's difficult and I thought so myself.

ROFL, paging is easy. We shall see.

[Octacone]

There is a difference between passing a null address and passing an address to an empty string. If I had to guess, I'd say that your code is passing a null address.

No worries, I fixed it.
For all future generations reading this: don't be stupid like me and instead of PrintStringFunction use PrintCharacterFunction and everything should be just fine.

Thats what I told you before didnt I?

Hmm... Did you? Lol, I forgot. oops

[Octacone]

Hmm, about that slave master EOI sending etc, I already have that function inside my IRQ_Handler that does the same exact thing, to just copy paste it inside my Keyboard_Handler and Timer_Handler?

What do you mean by it prints 16bit interrupt table? I don't think so, because it prints only what I tell it to print. Little bit confused in there. Drawing from RAM??? I don't have any kind of memory management set up and I don't interact with RAM as fair as I know, or maybe I do?

What I meant to say is that whenever I see that pattern on the screen, with three horizontal lines and an S, it looks like what you would see if you copied the bytes starting at RAM address zero to the screen.

RAM address 0000:0000 is where the interrupt handler table is located when the machine first boots. My guess is that you are (accidentally) passing the wrong address to your print string function, and from the looks of the screen, I'm guessing that your print string function is attempting to draw whatever string is sitting at memory address zero.

Maybe that is a hint to help you track down the actual problem, but I could be wrong.

Hmm, about that slave master EOI sending etc, I already have that function inside my IRQ_Handler that does the same exact thing, to just copy paste it inside my Keyboard_Handler and Timer_Handler?

No, you only have to send the EOI once per interrupt (for each PIC, of course). Your original code looks like you were sending it twice per interrupt. I'm assuming that's fixed now.

Now, I get it. Thanks for explaining. I send EOI only once per interrupts as supposed to, everything works just okay.

[ajxs]

Code: Select all

void ps2_wait_write()
{
	while(inb(0x64) & 2 == 0);
}

void ps2_wait_read()
{
	while(inb(0x64) & 1 == 0);
}

Are you positive this works as intended?
Shouldn't this be:

Code: Select all

void ps2_wait_write()
{
	while((inb(0x64) & 2) != 0);
}

void ps2_wait_read()
{
	while((inb(0x64) & 1) != 0);
}

You'll need to add the extra set of (...) brackets, since ==/!= operators have a higher precedence than bitwise operators, so the condition for the while loop in your wait functions won't ever be satisfied. ( depending on how your compiler interprets this. gcc actually generates a warning from your code with -Wall )