首先摘一段網上的見解：
the enable_irq unbalanced messages are harmless. it just means that when the driver called disable_irq there were no devices already using the irq, and as such it was already disabled, so the call to disable_irq was forgotten by the kernel, so when we call enable_irq the core kernel code thinks it's unbalanced when it isn't.
我們再來跟一下這個unbalanced的**：
void enable_irq(unsigned int irq)
else if (!--desc->disable_depth)
}spin_unlock_irqrestore(&irq_controller_lock, flags);
}可見unbalanced這個問題只會發生在enalbe_irq函式中，這裡要提到乙個變數disable_depth，這是乙個標誌中斷禁止否 的變數，如果呼叫disabled，這個變數會++，是正數，表示禁止中斷，如果是enable，這個變數會--，是0，表示允許，一般都會一一對應。
而如果這個變數本身就是0，enable的時候，我們再去enable它的時候系統會去檢查你這個是不是0，如果是0的話表示你這個中斷本來就是開啟的，你現在再去開啟沒有必要，這就是unbalanced了，所以可見這本身就是乙個無害的資訊。
Linux中斷和中斷處理
眾所周知，處理器的速度跟外圍的硬體裝置的速度往往不在乙個數量級上，因此，如果核心採取讓處理器傳送乙個請求，然後專門等待回應的辦法，顯然差強人意。既然硬體處理的這麼慢，那麼核心就應該在這期間去處理其他事務，等待硬體真正完成了請求的操作後，再回過頭來對它進行處理。輪詢 polling 可能會是一種解決辦...
linux中斷巢狀以及中斷丟失
在linux核心裡，如果驅動在申請註冊中斷的時候沒有特別的指定，do irq在做中斷響應的時候，是開啟中斷的，如果在驅動的中斷處理函式正在執行的過程中，出現同一裝置的中斷或者不同裝置的中斷，這時候新的中斷會被立即處理，還是被pending，等當前中斷處理完成後，再做處理。在2.4和2.6核心裡，關於...
linux中斷巢狀以及中斷丟失
在linux核心裡，如果驅動在申請註冊中斷的時候沒有特別的指定，do irq在做中斷響應的時候，是開啟中斷的，如果在驅動的中斷處理函式正在執行的過程中，出現同一裝置的中斷或者不同裝置的中斷，這時候新的中斷會被立即處理，還是被pending，等當前中斷處理完成後，再做處理。在2.4和2.6核心裡，關於...