工程人員最怕遇到隨機出現的bug，尤其是IC廠的軟體工程師，既要懷疑自己的軟體流程，又要同時有能力區分是否為IC bug（因為硬體出錯的機率相較於PC平台來說高出很多...）。最近面對一個bug，竟然花了兩週的時間才整個釐清並解決...事後自己反省，覺得有很多值得改善的地方。
問題是這樣的：當系統開機時，發現我負責的模組在約40s~50s左右會隨機的timeout，或遭遇奇怪的錯誤情況，最後讓整個系統當掉。
由於單獨模組都已經通過了壓力測試，所以我第一個反應就是先檢查硬體。觀察了外部訊號，但沒有發現任何異樣。接著觀察相關registers，發現掛掉的時候讀到了非常奇怪的數值。由於該數值是controller直接從DRAM獲得，所以有可能是DRAM不穩嗎？不對，因為幾乎每次都掛在我這邊，如果是DRAM不穩，那應該到處都會著火。
那麼，是bus上出問題嗎？一想到這，心就涼了半截...但還是硬著頭皮觀察IC內部bus訊號（AHB signal，嗯，你不用在乎這是什麼 XD）結果，真的發現在發生問題時，bus signal非常的異常。這下designer緊張了，這可能會影響到是否已下單的wafer是否全部泡湯的問題。於是，一堆人開始出主意：有沒有試過ooo、有沒有試過xxx、＃＄％︿＆＊＊（！...
由於出意見的人都是有掛頭銜的，所以往往都要先確認他們的意見是否成立。嗯，這是我犯的第一個大錯：
花了太多時間應付長官的要求，而非處理事情的本質。
由於長官並不那麼清楚整個始末，但又因為可能是大問題，所以自然吸引人們出意見。但是我應該在當時就說明清楚，而不是默默承受無釐頭的要求（懂得何時說"No"就跟懂得何時說"Yes"一樣重要）。嗯...總之，這樣一個禮拜就過去了，客戶也開始著急了起來，質疑什麼問題需要一週還沒任何結論。
接著，長官們沒想法後，總算可以開始自己的實驗，很快地發現某個模組只要一發生錯誤，我的部份再過幾秒後就出問題。所以將重點移到該模組。詢問該模組負責人相關流程後，對於為何會出錯也很納悶，畢竟...嗯，他自己單獨跑也是經過了好幾天的測試...好了，所以問題是出在兩者間的交互作用導致bus出問題嗎？於是我們開始了這兩個模組的co-sim, FPGA CVT...這邊則是我的第二個錯誤：
在進行之前已作過的實驗之前，應先確認目前流程與之前的差異。
笨蛋往往會重複已經重複過的事情，但有趣的是：程式設計師有時會自動變笨蛋。XD
又過了幾天，依然無法在單純的環境複製出來，在無計可施的情況下，於是我抓了對方的code來研究一下，不看還好，一看暈倒...原來在他的模組發生問題時（某種有趣的條件下），過了一段時間，driver對bus bridge做了reset...只因為該模組的名稱與bridge的名稱差幾個字母，於是敲錯了...對bus bridge reset自然就會讓當時在bus動作的模組死得奇奇怪怪...這邊我犯了第三個錯誤：
基於莫名的code所有權觀念，我自覺不該隨意質疑別人的code。
但是這在健康的團體中，是不應該存在的。code是大家共有的。尤其在發生問題時，應該透過理性，並且客氣的方式進行討論與review。如果我們能更早地向對方簡述自己的程式流程（小鴨debug法？），這種問題應該在第一時間就抓到。
隨著工作經驗的增長，發現自己仍然需要針對許多處理事情的行動細節加以改善。這次的失誤，就當作給自己的警惕，並且為久旱的blog添點水分。 :-)
留言
張貼留言