IRQ Problems

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
srg_13

IRQ Problems

Post by srg_13 »

Hey,

I have recently added fault and IRQ handling to my OS, with an IDT. I know that the IDT is installed properly, as I can crash the OS, and the exception handler can halt the OS and display a message. The ISRs for the IRQs and the exceptions are installed and handled in almost exactly the same way. The problem is that I never receive any interrupts. The IRQ handler is never even called. Why is this happenning?? I have enabled interupts with the ASM sti command.

Can you give me an answer with the information I have provided, or would you need to see the code??

Thank you in advance,

Stephen
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:

Re:IRQ Problems

Post by Brendan »

Hi,

Have you tried the FAQ?

[move]Click Me![/move]

Cheers,

Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
srg_13

Re:IRQ Problems

Post by srg_13 »

I have now ;)

But its still not working. I know that the ISR is srt up correctly, and I know that the IRQs are firing, as if I comment out the function call to remap the PIC, i receive a double fault. Here is the code I'm using:

The ASM:

Code: Select all

global _irq0
...              
global _irq15

; 32: IRQ0
_irq0:
    cli
    push byte 0   
    push byte 32
    jmp irq_common_stub

; and so on...

; 47: IRQ15
_irq15:
    cli
    push byte 0
    push byte 47
    jmp irq_common_stub

extern _irq_handler

; This is a stub that we have created for IRQ based ISRs. This calls
; '_irq_handler' in our C code. We need to create this in an 'irq.c'
irq_common_stub:
    pusha
    push ds
    push es
    push fs
    push gs
    mov ax, 0x10
    mov ds, ax
    mov es, ax
    mov fs, ax
    mov gs, ax
    mov eax, esp
    push eax
    mov eax, _irq_handler
    call eax
    pop eax
    pop gs
    pop fs
    pop es
    pop ds
    popa
    add esp, 8
    iret
The C Code

Code: Select all

extern void irq0();
// ....
extern void irq15();

void *irq_routines[16] =
{
    0, 0, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 0, 0
};


void irq_install_handler(int irq, void (*handler)(struct regs *r))
{
    irq_routines[irq] = handler;
}


void irq_uninstall_handler(int irq)
{
    irq_routines[irq] = 0;
}

void irq_remap(void)
{
    outportb(0x20, 0x11);
    outportb(0xA0, 0x11);
    outportb(0x21, 0x20);
    outportb(0xA1, 0x28);
    outportb(0x21, 0x04);
    outportb(0xA1, 0x02);
    outportb(0x21, 0x01);
    outportb(0xA1, 0x01);
    outportb(0x21, 0x0);
    outportb(0xA1, 0x0);
}

void irq_install()
{
    irq_remap();

    idt_set_gate(32, (unsigned)irq0, 0x08, 0x8E);

    //   ...        And so on...

    idt_set_gate(47, (unsigned)irq15, 0x08, 0x8E);
}

void irq_handler(struct regs *r)
{
    /* This is a blank function pointer */
    void (*handler)(struct regs *r);

    handler = irq_routines[r->int_no - 32];
    if (handler)
    {
        handler(r);
    }

    if (r->int_no >= 40)
    {
        outportb(0xA0, 0x20);
    }

    outportb(0x20, 0x20);
}
The code is from Bran's Kernel Development

-Stephen
Warrior

Re:IRQ Problems

Post by Warrior »

You must remap the PIC or when your IRQs fire your exception handler will be mistakenly called.
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:

Re:IRQ Problems

Post by Brendan »

Hi,
Stephen wrote:But its still not working. I know that the ISR is srt up correctly, and I know that the IRQs are firing, as if I comment out the function call to remap the PIC, i receive a double fault. Here is the code I'm using:
I didn't find anything wrong with the code posted. I also took a quick look at Bran's tutorial and didn't see any bugs there either.

The part of Bran's tutorial I liked the most is the first 2 sentences of the introduction:

"Kernel development is not an easy task. This is a testament to your programming expertise: To develop a kernel is to say that you understand how to create software that interfaces with and manages the hardware."

From what I can tell, most people who read these lines end up grabbing GRUB and then use cut & paste as the beginning of their "testament to programming expertise". Invariably, at the first problem they encounter they find they lack the prior learning to figure out what's wrong.

I can't help wondering if it'd be better in the long run to delete Bran's tutorial from all computers, and make people learn about what they're doing instead. *shrug*


Cheers,

Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Warrior

Re:IRQ Problems

Post by Warrior »

The OSFAQ has a section on IRQs and ISRs
User avatar
Pype.Clicker
Member
Member
Posts: 5964
Joined: Wed Oct 18, 2006 2:31 am
Location: In a galaxy, far, far away
Contact:

Re:IRQ Problems

Post by Pype.Clicker »

what if you remap, but don't touch the masks ?
Crazed123

Re:IRQ Problems

Post by Crazed123 »

Brendan wrote: Hi,
Stephen wrote:But its still not working. I know that the ISR is srt up correctly, and I know that the IRQs are firing, as if I comment out the function call to remap the PIC, i receive a double fault. Here is the code I'm using:
I didn't find anything wrong with the code posted. I also took a quick look at Bran's tutorial and didn't see any bugs there either.

The part of Bran's tutorial I liked the most is the first 2 sentences of the introduction:

"Kernel development is not an easy task. This is a testament to your programming expertise: To develop a kernel is to say that you understand how to create software that interfaces with and manages the hardware."

From what I can tell, most people who read these lines end up grabbing GRUB and then use cut & paste as the beginning of their "testament to programming expertise". Invariably, at the first problem they encounter they find they lack the prior learning to figure out what's wrong.

I can't help wondering if it'd be better in the long run to delete Bran's tutorial from all computers, and make people learn about what they're doing instead. *shrug*


Cheers,

Brendan
Or how about we not delete a valuable and useful resource for those wishing to learn about kernels? Not all information on the subject can be easily read/gleaned/inferred from Intel manuals, and people have to learn somehow.

Now if you want something that should be banned from the net, how about Unix workalikes (starting a deliberate debate here). IMHO there are just too many people who get into kernel development and say "Well, I think I'll make Yet Another Unix with full POSIX compliance, but I'll add neat feature X to the scheduler or maybe a new GUI system." We already have 5-7 open source Unix workalikes floating around the net, including Linux, the BSDs and Minix. If you want to write kernel-level Unix WORK ON ONE OF THOSE.
Warrior

Re:IRQ Problems

Post by Warrior »

My stand on this is let them copy code all they want, eventually they will get stuck. Hopefully they will come into realization if they havn't already abandoned the project all together.
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:

Re:IRQ Problems

Post by Brendan »

Hi,

Perhaps my comments on Bran's tutorial were a little harsh.

I just think it'd be better to start with a "kernel design tutorial" rather than a "kernel implementation tutorial".

The tutorial would start by describing different kernel types (advantages and disadvantages) and then move on to memory management (segmentation, paging, algorithms, etc) and the alternatives for scheduling and IPC.

After this would be "Part II" where the implementation side of things begins. This would contain descriptions of the boot processes (from "power on" until the boot sector is loaded), CPU modes, tools (linking, etc), IRQ handling, A20 gate, emulators, debugging, etc. It wouldn't contain any code at all. Instead there'd be "pseudo code" and a lot of links to other material (like Intel's manuals, the FAQ, etc).

The idea would be to make people aware of all the design alternatives (so they can create a design they want rather than starting with a "pre-packaged" design), then make it easy for them to learn what they need to start implementing (without spoon-feeding them code) and make sure they can find more detailed information when necessary.


Cheers,

Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Crazed123

Re:IRQ Problems

Post by Crazed123 »

Sounds like you have some ideas, and "Brendan's Kernel Tutorials Parts 1 and 2" sounds quite nice...
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:

Re:IRQ Problems

Post by Brendan »

Hi,
Crazed123 wrote:Sounds like you have some ideas, and "Brendan's Kernel Tutorials Parts 1 and 2" sounds quite nice...
If I were to begin something like this it'd be a book, where part III contains some of the source code for a micro-kernel based OS. The CD that comes with the book would be bootable, and would contain documentation for the OS and all of the source code in cross-linked html format....


Cheers,

Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
srg_13

Re:IRQ Problems

Post by srg_13 »

I fixed it!

The old code's definitions had interrupts 32 to 47 as IRQ 1-15, but I changed this to 21-36.

I am now writing a new interupt driven keyboard driver. I have also set up the PIT. I have to fix the mouse driver now, as I get a general protection fault when I move the mouse :P.

-Stephen
Crazed123

Re:IRQ Problems

Post by Crazed123 »

Brendan wrote: Hi,
Crazed123 wrote:Sounds like you have some ideas, and "Brendan's Kernel Tutorials Parts 1 and 2" sounds quite nice...
If I were to begin something like this it'd be a book, where part III contains some of the source code for a micro-kernel based OS. The CD that comes with the book would be bootable, and would contain documentation for the OS and all of the source code in cross-linked html format....


Cheers,

Brendan
Cool, like an Uber-Minix.
User avatar
Colonel Kernel
Member
Member
Posts: 1437
Joined: Tue Oct 17, 2006 6:06 pm
Location: Vancouver, BC, Canada
Contact:

Re:IRQ Problems

Post by Colonel Kernel »

Crazed123 wrote:
Brendan wrote: Hi,
Crazed123 wrote:Sounds like you have some ideas, and "Brendan's Kernel Tutorials Parts 1 and 2" sounds quite nice...
If I were to begin something like this it'd be a book, where part III contains some of the source code for a micro-kernel based OS. The CD that comes with the book would be bootable, and would contain documentation for the OS and all of the source code in cross-linked html format....


Cheers,

Brendan
Cool, like an Uber-Minix.
Except all the code would be assembler, thus limiting the target audience considerably. ;)
Top three reasons why my OS project died:
  1. Too much overtime at work
  2. Got married
  3. My brain got stuck in an infinite loop while trying to design the memory manager
Don't let this happen to you!
Post Reply