悟空討厭關中斷，關中斷很暴力，但是再暴力也比導致系統異常好，所以悟空決定將所有的發送隊列的自旋鎖都使用關中斷的自旋鎖。修改完代碼之後，悟空很開心，因爲這是悟空第一次改正大牛錯誤的代碼，能夠找到別人的錯誤這讓悟空很開心。但是測試的結果讓悟空欲哭無淚，因爲測試的結果告訴悟空，加鎖之後的確保證標誌位和802.11協議棧的狀態保持了一致，但是另一個奇怪的問題出現了。802.11協議棧一直處於掛起狀態，而一直沒有被喚醒，因此依然出現了上面的假死問題，悟空只能再次找來了圓方商量對策。
悟空曰：爲什麼802.11協議棧一直處於掛起狀態，爲什麼一直無法喚醒呢?
圓方曰：要知道爲什麼沒有喚醒，我們需要先來看看驅動程序是如何喚醒該網絡協議棧的。和前面一樣，我們再來分析一下喚醒的流程。
從這個流程我們可以看出，其實喚醒的流程是由硬件中斷引起的，如果硬件不在觸發中斷了，或者硬件觸發了中斷，但是被系統給丟失了，那麼一旦協議棧掛起了，系統也就永遠無法喚醒了。
悟空曰：哦原來是這樣啊，那麼什麼情況會導致系統不再觸發中斷了呢?
圓方曰：當硬件出了故障之後，可能導致系統不再觸發中斷。當然這個問題的可能性不大，因爲不可能我們所有的硬件都出了問題，所以這個可能性幾乎可以排除。
悟空曰：那麼什麼情況下又可能導致系統丟掉中斷呢?
圓方曰：一般這個問題是由系統設計的時候關中斷的時間太長導致的，所以在使用關中斷自旋鎖的時候一定要注意關中斷的粒度問題，臨界區數據的同步問題，又要保證關中斷的粒度不能太大。
聽到這裏悟空心裏明白了，應該是自己的關中斷的時間太長導致了這個新的問題，但是對於這個粒度，實在難於保握。所以悟空想起圓方一起看看他的修改，看是否可以將關中斷的粒度調小。但是圓方告訴悟空，其實他也不會，自始至終他都沒有看過該無線驅動，他只是分析了該無線驅動官方提供的文檔。