※ 引述《roylee17 (把我id還我阿......)》之銘言： : ※ 引述《musicguitar ()》之銘言： : : 想請問. : : 如果使用一個share的interrupt.也就是除了我自己的裝置會觸發這個中斷 : : 其他裝置也會觸發. : : (實際上這個是X86裡的IRQ9.ACPI interrupt,我需要知道GPE0 觸發訊號) ===================================================================== 再敘一下問題: 你的裝置跟系統裡的其他裝置會共用 IRQ9.ACPI 這個 interrupt line. 因為是共用, 是否該考慮 mutual exclusive lock 的問題? : : 我是否需要做spin lock或是semaphore去做lock的動作. : 需要 lock 與否，是取決你要存取的資料是否共享 : 而不是因為 irq 是不是共用 首先, 共用的現象是存在的, 至少共用了 interrupt-request line 造成 irq-request flag raised. 考慮的問題就是: 1. 如果你的 device 跟 共用那條 request line 的系統裝置 "同時" 都產生中斷請求, 何者會先被處理? 先處理的會不會影響另者不 會被處理或者造成失誤? 2. "同時" 的含義包含在前者發生中斷且已進入 ISR 處理, 但尚未離 開 ISR 程式, 後來者就 "同時" 也已產生中斷請求. 3. 急速連續請求, 也會發生同一裝置在 ISR 處理時 "同時發生" 下 一個請求. PC 的 ACPI 是可變換/設定 訊號來源線接續 及 產出中斷的 IRQ-n, 系統通常是自動錯開分配, 除非強制共用一個 IRQ-N , PC硬體現在很 便宜, 可以擴充串接幾個 Programmable Interrupt Controller, 很少 像往日透過 I/O bus 共用同一條 interrupt line. 要共用同一條線就 要考慮 edge trigger 還是 level trigger, 這涉及到 "同時" 發生時 能否檢測到兩(多)個中斷請求. 若是分離的請求線, 但使用同一個 IRQ -n 輸出向量入口, 因不同輸入線容易讀出判斷較不容易混淆. X86 中斷的機制是 CPU 會接受中斷一定是處於 EI Flag 狀態, 一旦接 受就轉入 DI , 這就是一種防止ISR 再進入(re-entrant)的硬體 lock 機制. 如果是單核單處理機, 最簡單的 software mutual exclusive lock implementation 就是 DI/EI 就互斥共用鎖定言, ISR 程式在未結束前不做 EI 就是擋住共用或下一 個同時的中斷請求闖進來, 避免造成 shared ISR 用到的 register/ stack/data-memory 引起相互干擾的混亂. : : 因為我在kernel 2.6.32使用這兩個lock都會出現kernel error(類似kernel bug)的訊息. : : 我的ISR所做的事是去動作I2C.讀取device的暫存器. : ^^^^^^^^^^^^^^^^^^ : 除了你的 ISR 外，有其他的 code flow 會存取這個暫存器嗎？ : 另外，ISR 中，不適用 semaphore : 或是其他需要 process context 的同步機制 ISR 理論上已是 OS Kernel 最底層的工作, 不會再叫用其他程式 頂多就是 set event flag. : spin lock 應該是沒問題的(需不需要是另外一回事) : 如果你的 lock 是自己建的，記得初始化 : 如果是 lock 系統中現有的某個 lock， : 那要檢查一下整個 lock 的使用情況， : 你有沒有 double lock/unlock : error message 可以貼上來 : : 另外.我曾在kernel 2.6.29中.semaphore不會出現error.只有spin lock會! : : 所以我覺得奇怪.ISR中.到底需不需要再做lock的動作. : : 因為我一lock就當機了!!!所以我現在是把lock都拿掉了!! : : 不知道會不會出問題... 若請求不夠密集不是太快, 只要不隨意進行 EI 就很難有麻煩. ※ 編輯: ggg12345 來自: 140.115.4.12 (03/04 20:53) ※ 編輯: ggg12345 來自: 140.115.4.12 (03/05 12:39)