2

我正在开发一个操作系统，我正在尝试让一个 PIC 计时器工作。它是一个在保护模式下运行的 32 位操作系统。这段代码挂起操作系统，（我不知道为什么，这就是我想要找出的）。我正在清除 IRQ0 掩码。这段代码有什么问题，还是 IDT 或 PIC 有问题？此外，我有几个软件中断处理程序工作得很好，所以我认为它与 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
4

1 回答 1

1

您应该始终尽可能缩短您的中断子例程。与 x86 架构一起使用的 PIC 将使用它的掩码同时处理相同优先级的中断，但是当中断发生在 ISR 内时就会出现问题。我认为可能是更好的方法是简单地提高一个标志（将一个可从 ISR 访问的变量设置为 True 或其他），并且在您的操作系统分配的量子之间，您可以如您所展示的那样刷新您的掩码。或者使用一个 quanta 来完成它，因为您的调度策略认为合适。如果您的操作系统不是抢占式的，您可能希望退出 ISR，进行刷新，然后返回到用户程序。

不过，您的问题似乎不是这个。您应该获得一个好的调试器或仿真器，以便能够了解您的情况会发生什么。

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.

于 2012-09-02T18:40:05.970 回答