OSDev.org

Posted: **Wed Jul 27, 2016 5:35 am**

Your PS2_WaitWrite function is wrong. Change the == to !=.

Posted: **Wed Jul 27, 2016 6:49 am**

SpyderTL wrote:Your PS2_WaitWrite function is wrong. Change the == to !=.

Nice catch! That might be why it didn't work for other guys that have their IRQs working.
The question still remains: why doesn't my IRQ handler call appropriate functions (in this case keyboard_handler) once the interrupt occurred?

3rd day, still no luck. I can't image what is going to happen once I start coding paging.

Posted: **Wed Jul 27, 2016 7:55 am**

omarrx024

I discovered something related to your code.
When I enable this line: PS2_Send(0xFF); //for those who don't know what this is, see my screenshot
After that point nothing gets executed, I don't see the rest of my output that I am supposed to see, suggesting that my kernel is hanging, when I disable that line everything executes as usual.

Posted: **Wed Jul 27, 2016 9:45 am**

WTF!!! I am loosing my mind...
I was not enabling interrupts after I installed my IDT and unmasked IRQs etc... Now I added __asm__ __volatile__ ("sti"); and when I enabled Timer_Wait(10); or I enable while(1); I get infinite IRQ32(aka IRQ0) interrupts. See my screenshot.

Timer code:

Code: Select all

volatile unsigned int timer_ticks = 0;

struct regs
{
	unsigned int gs, fs, es, ds;      
	unsigned int edi, esi, ebp, esp, ebx, edx, ecx, eax;  
	unsigned int int_no, err_code;   
	unsigned int eip, cs, eflags, useresp, ss;   
};

void Timer_Handler(struct regs *r)
{
	timer_ticks++;
	PIC_SendEOI(0);
	if (timer_ticks % 18 == 0)
    	{
    		
	PIC_SendEOI(0);
        		PrintString("\nOne second has passed");
        		WriteOutputToQemu("One second has passed");
    	}
}

void InstallTimer()
{
	IRQ_Install_Handler(32, (unsigned)Timer_Handler);
}

void TimerWait(int ticks)
{
	unsigned int eticks;
	eticks = timer_ticks + ticks;
	while(timer_ticks < eticks) 
	{
        		__asm__ __volatile__("hlt");
	}
}

Posted: **Wed Jul 27, 2016 10:50 am**

Make sure to send EOI to the PIC.
It will resend you the interrupt until you acknowledge and say you received it.

Also why do I see so many calls to PIC_SendEOI(0); in your code?
Its ONLY supposed to be called after you received an interrupt..

Posted: **Wed Jul 27, 2016 11:00 am**

Ch4ozz wrote:Make sure to send EOI to the PIC.
It will resend you the interrupt until you acknowledge and say you received it.

Also why do I see so many calls to PIC_SendEOI(0); in your code?
Its ONLY supposed to be called after you received an interrupt..

YESSSSSSS
I was trying random fixes and then

I should change my install sequences so what I did
1.GDT
2.IDT
3.ISRS
4.TIMER
5.KEYBOARD
6.IRQ
7.STI
8.REMAP PICS //I removed this since I already had a function remap_irq that did the same thing
Then I changed from 33 to 1 and from 32 to 0 and enabled while(1); enabled my timer and bammmmmmmmmmmm my keyboard handler and timer handler got called!!! But I can only get interrupts if I enabled while(1); inside my kernel.c

Do I need to use clear mask and set mask functions?
Why do I only get interrupts when I enabled while(1); inside my kernel?
Should I use SendEOI Inside my kbd and timer handlers?

Posted: **Wed Jul 27, 2016 1:12 pm**

Please answer this: Why I don't get any interrupts when I don't have while(1) loop?

When I enable while(1) loop I can use my timer and my keyboard. But I get these weird glyphs:
How I print my characters: PrintString(kbdus[scancode]);

Posted: **Wed Jul 27, 2016 2:08 pm**

thehardcoreOS wrote:omarrx024

I discovered something related to your code.
When I enable this line: PS2_Send(0xFF); //for those who don't know what this is, see my screenshot
After that point nothing gets executed, I don't see the rest of my output that I am supposed to see, suggesting that my kernel is hanging, when I disable that line everything executes as usual.

That's very odd, because the PS/2 keyboard should be reset before initialization. My OS uses the PS/2 keyboard reset and works on Bochs, QEMU, VirtualBox, VMware, two tested PCs, and really everywhere.

Posted: **Wed Jul 27, 2016 2:13 pm**

omarrx024 wrote:
thehardcoreOS wrote:omarrx024

I discovered something related to your code.
When I enable this line: PS2_Send(0xFF); //for those who don't know what this is, see my screenshot
After that point nothing gets executed, I don't see the rest of my output that I am supposed to see, suggesting that my kernel is hanging, when I disable that line everything executes as usual.
That's very odd, because the PS/2 keyboard should be reset before initialization. My OS uses the PS/2 keyboard reset and works on Bochs, QEMU, VirtualBox, VMware, two tested PCs, and really everywhere.

I don't know, maybe it is something else, or just your hardware.

By the way can you answer the question I asked? (one post up)

Posted: **Wed Jul 27, 2016 2:18 pm**

thehardcoreOS wrote:
omarrx024 wrote:
thehardcoreOS wrote:omarrx024

I discovered something related to your code.
When I enable this line: PS2_Send(0xFF); //for those who don't know what this is, see my screenshot
After that point nothing gets executed, I don't see the rest of my output that I am supposed to see, suggesting that my kernel is hanging, when I disable that line everything executes as usual.
That's very odd, because the PS/2 keyboard should be reset before initialization. My OS uses the PS/2 keyboard reset and works on Bochs, QEMU, VirtualBox, VMware, two tested PCs, and really everywhere.
I don't know, maybe it is something else, or just your hardware.

By the way can you answer the question I asked? (one post up)

Without the while(1) your main function will be left and returns to your GRUB entry point of the kernel.
If you followed some tutorials it will usually do "CLI; HLT;"
You can put

Code: Select all

asm volatile("hlt");

into your while(1) so no CPU is used until an interrupt occurs.

Posted: **Wed Jul 27, 2016 2:25 pm**

Ch4ozz wrote:
Without the while(1) your main function will be left and returns to your GRUB entry point of the kernel.
If you followed some tutorials it will usually do "CLI; HLT;"
You can put
Code: Select all
asm volatile("hlt");
into your while(1) so no CPU is used until an interrupt occurs.

Ch4ozz so I have to use that freaky while loop.

RIP that means I can't use them anywhere else since I don't have multitasking.
Btw what are those weird characters called and why am I getting them?
PrintString(kbdus[scancode]);
kbdus == unsigned char[] array filled with co-responding strings

Posted: **Wed Jul 27, 2016 2:42 pm**

thehardcoreOS wrote:Please answer this: Why I don't get any interrupts when I don't have while(1) loop?

Please don't use color formatting. Your C code probably returns to your assembly stub when you don't have a while(1); loop, and (assuming you copied the assembly stub from any tutorial) the assembly stub has a CLI, HLT after calling kmain. And the CLI/HLT combination prevents IRQs.

Posted: **Wed Jul 27, 2016 2:56 pm**

omarrx024 wrote:
thehardcoreOS wrote:Please answer this: Why I don't get any interrupts when I don't have while(1) loop?
Please don't use color formatting. Your C code probably returns to your assembly stub when you don't have a while(1); loop, and (assuming you copied the assembly stub from any tutorial) the assembly stub has a CLI, HLT after calling kmain. And the CLI/HLT combination prevents IRQs.

Hmm, you guys hate colors.
Yeah I have something like

Code: Select all

cli
call Kernel_Main
hlt
jmp $

I must use while loop in order for my interrupts to work, as suggested by other people.
Why are those glyphs appearing?

Posted: **Wed Jul 27, 2016 3:01 pm**

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.

Posted: **Wed Jul 27, 2016 3:05 pm**

thehardcoreOS wrote: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.

thehardcoreOS wrote: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..

)

OSDev.org

[Solved] IRQ Firing Bug

Re: IRQ Firing Bug

Re: IRQ Firing Bug

Re: IRQ Firing Bug

Re: IRQ Firing Bug

Re: IRQ Firing Bug

Re: IRQ Firing Bug

Re: IRQ Firing Bug

Re: IRQ Firing Bug

Re: IRQ Firing Bug

Re: IRQ Firing Bug

Re: IRQ Firing Bug

Re: IRQ Firing Bug

Re: IRQ Firing Bug

Re: IRQ Firing Bug

Re: IRQ Firing Bug