在这份文件中，http://retired.beyondlogic.org/serial/serial1.htm#30，
COM3的IRQ为4，其中断向量为0C。
但是int 0C中断向量是为Stack Fault保留的....
这很令人困惑。当COM3中断时，堆栈故障同时发生？
beyondlogic.com表显示了BIOS设置的默认映射，从IRQ（进入可编程中断控制器（PIC）的外部中断信号）到CPU看到的中断或异常编号。因此，在这种情况下，来自串行端口的中断线连接到PIC输入3，当置位时，CPU输入3将使CPU运行中断向量表中的条目0xC指向的中断/异常处理程序。
CPU内部生成的异常也会发生同样的情况。要继续您的示例，堆栈错误会导致运行中断向量表中的条目0xC指向的异常处理程序。
因此，在这种情况下，不是串口中断导致堆栈错误，而是两个不同的事件可能导致相同的中断/异常处理程序运行。
这种冲突是不可取的。从理论上讲，中断/异常处理程序代码可以检查实际导致处理程序运行的原因，但这需要时间，因此我们需要一个更好的解决方案。
然而，首先值得一看的是首先引起这场冲突的原因。英特尔总是为内部异常保留小于0x20的条目，但在8086上只使用了0到4的条目，因此当原始IBM PC映射中断到8及以上时这不是问题。
随着80386和保护模式的引入，异常数量增加，现在使用条目5到0x14，这意味着当使用默认IRQ映射时，中断可能发生冲突。
因此，在保护模式下运行的大多数现代操作系统使用的解决方案是重新编程PIC，以便中断使用0x20或更大的中断向量。有关更多详细信息，请参阅OSDev.org，或查看具体示例，了解Linux如何做到这一点。