x86 Clearing IRQ mask hangs OS

Question

I am developing an OS and I am trying to get a PIC timer working. It is a 32 bit OS running in protected mode. This code hangs the OS , (I have no idea why , that is what I am trying to find out). I am clearing IRQ0 mask. Is there anything wrong with this code or is it something with the IDT or PIC? Also I have several software interrupt handlers that work just fine so I don't think it is with the IDT.

      public static void IRQ_clear_mask(byte IRQline)
    {
        ushort port;
        byte value;

        if (IRQline < 8)
        {
            port = 0x21;
        }
        else
        {
            port = 0xA1;
            IRQline -= 8;
        }
        value = (byte)(GruntyOS.IO.Ports.Inb(port) & ~(1 << IRQline));
        GruntyOS.IO.Ports.Outb(port, value);
    }



mov byte [_NATIVE_IDT_Contents + 254], AL
        mov byte [_NATIVE_IDT_Contents + 255], AH
        mov dword EAX, irq_common_stub
        mov byte [_NATIVE_IDT_Contents + 0x100], AL
        mov byte [_NATIVE_IDT_Contents + 0x101], AH
        mov byte [_NATIVE_IDT_Contents + 0x102], 0x8
        mov byte [_NATIVE_IDT_Contents + 0x105], 0x8E

Answer 1

You should always keep your Interrupt Sub-Routines the shortest possible. The PIC used alongside x86 architectures will handle simultaneous same-priority interrupts using its mask, but problem arises when interrupts happens inside an ISR. What I think may be a better way to do it is simply raising a flag (putting a variable accessible from your ISR to True or else) and between your OS allocated quantas, you can flush your masks as you have shown. Or use a quanta to do it, as your scheduling strategy see fit. If your OS is not preemptive, you may want to exit the ISR, do the flushing and then return to user programs.

Your problem doesn't seem to be this, though. You should get a good debugger or emulator to be able to understand what happens in your case.

If an uninitialized interrupt is raised, this behavior can happen. You should check, with a debugger if you can, where your OS execution is when it crashes. Did it enter an generic IRQ function which stall the CPU? This is the default behavior on multiple embedded chips.