Sense Code Message

在LSI IMR產品於event log中常常會看到以下這種形式的日誌紀錄:

此紀錄是為LSI的感測代碼(Sense Code)型式. 這種未預期(Unexpected)的代碼通常可以具體的判讀目前RAID controller究竟發發生了何種狀況?時間點與目的. 但是他有一個缺點, 從人類行為角度觀來看, 他並不好閱讀. 通常要進行人為上的解碼(decoding), 因此需要花費一些時間.

根據Intel的一份LSI RAID訓練文件顯示出改測代碼的基本佈局(layout). 如下圖所示:

根據上圖通常要在乎的是c到g的區塊. 重點在於f之後的區塊. 顯然在LSI RAID維護上, 感測代碼的解讀是相當重要且有意義的一環.f之後的區塊所呈現的形式如下:

Unexpected Sense Codes are error messages that are generated when a device attached to a RAID controller encounters an error and responds with a device based error message.
雖然感測代碼主要描述的錯誤問題(issue)的產生, 但並非全然都是設備問題點的產生. 具體上它只是描述當前的例外情況(exception). LSI IMR controller是如何導引這些代碼的產生, 如下表示:
1. IMR HBA會觸發相關命令與當前狀態的更新.
2. 如果設備端(target)的狀態並不是good(00h), 控制器會觸發REQUEST SENSE命令到設備端.
3. 從一個REQUEST SENSE回應的非預期感測代碼並且包含CDB(Command Data Block)的組成會被處理.
4. CDB包含發送到設備端的命令以及相關的感測數據包含從設備端發送的錯誤訊息, 訊息長度達到255bytes.
5. 一個被紀錄的項目包含以下的型式:
>>a. 事件的時間點
>>b. 引發的來源通道(channel)以及設備端
>>c. 符合標準的SAS/SATA CDB
>>d. 從設備端回傳的感測代碼(sense code)
6. 回傳的感測數據包含以下型式:
>>a. 感測鍵(SENSE key), byte 2, 識別唯一
>>b. 感測代碼訊息(sense code), byte12
>>c. 感測代碼修飾符(sense code qualifer), byte 13

所以以前面第二張圖的佈局的公式展現如下所示:

前面提到過, 最重要的關注點是在CDB in Hex與Sense in Hex的一大串編碼的解讀. 以前面第一張圖的範例來進行解讀:

包含了CDB和Sense code的佈局. 首先來釐清CDB的佈局格式, 如下圖所示:

拆成10組byte區塊, 以Hex型式呈現. 每組記錄不同的描述情況. 當然這是其中一種型式, LSI RAID controller可以描述4種不同長度的CDB訊息: 6, 10, 12, 16等這四種CDB長度. 上面的範例屬於長度為10的CDB. LSI在描述CDB最重要的是第0組的byte代碼, 是為operation code, 為發生的操作情況.
上述的10bytes規格,他的stack佈局可如下所示:

以下的三張圖為描述Operation Code的相關列表(list):

根據前面的範例:

byte 0為4d, 從list判讀出這是LOG SENSE的operation code, 所以基本確定這不是一個設備端錯誤的情況.