NTB調試常見問題指南

NTB調試常見問題指南

做爲實現不一樣PCI域乃至跨節點數據傳輸的重要器件，NTB在服務器和存儲領域實現雙控、內存互訪等方面發揮着重要的做用。因爲它自己既做爲virtual port出現，又能夠被互聯的結點經過pci scan看到，做爲一個link port出現，加之其上實現的地址轉換和轉發功能，在實際工程項目中，不免會碰到各類問題。本文結合筆者最近的工做，分享了NTB調試過程當中常見的問題和解決思路和辦法。

從問題的現象來看，具體常見問題包括：

找不到NTB設備；

NTB mailbox沒法傳送數據；

ReqID 沒法探測到；

NTB bar size 不夠大;

數據傳輸出錯

根據問題發生所在的PCIE相關的軟硬件層次，這些問題又能夠概括爲下面的幾類：

硬件故障；

固件故障；

PCIE 設置錯誤；

程序錯誤。

下面針對上面列舉出來的幾種現象，逐一進行分析和討論：

找不到NTB設備

這種狀況下，運行應用程序的時候可能會發現用刀的庫中會提示找不到設備，程序出錯或者退出。此時，能夠首先經過lspci看看可否掃描到NTB設備，若是找不到就說明系統沒有發現NTB硬件，此時須要檢查NTB的EEPROM是否已經使能NTB，以及板卡上是否有disable/enable NTB的跳線，若是有則還須要堅持它是否已經disable。若是設備存在，而且可以被lspci掃描到，可是應用程序就是提示看不到設備，須要檢查設備驅動是否加載成功。此時，能夠經過從新加載NTB設備驅動程序去解決。

二、NTB mailbox register沒法傳送數據

根據NTB的使用說明，通常而言，NTB的mailbox和doorbell寄存器用來在多個節點之間傳遞信息進而實現上層的同步。若是出現doorbell /mailbox寄存器讀回來的數是0xffffffff的話，那麼須要檢查映射doorbell/mailbox寄存器的bar0/1的設置是否正確。方法是經過lspci讀出bar0/1的值，檢查它是否和BIOS給它分配的物理地址一致。

三、ReqID沒法探測到

具體的現象以下面的輸出所示意：

Communicating from          : VIRTUAL side

Determine NT connect type   : Standard (NTV <---> NTL)

Get BAR 2 properties       : Ok (Size:2048 KB)

Map BAR 2 to user space    : Ok (VA:0x7f5c1801d000)

Probe for write ReqID      : ERROR: Unable to probe ReqID, auto-add 0,0,0

Add write Req ID to LUT    : ERROR: Unable to add LUT entry

Allocate PCI buffer        : Ok (PCI:3638A000  Size:1000 B)

Map PCI buffer             : Ok (VA:0x7f5c18d01000)

ReqID是用來記錄發出PCIE TLP請求的device的B：Ｄ：Ｆ，若是是由cpu發起的訪問，那麼它一般用北橋root cmplex的B:D:F來表示,若是是ＤＭＡ發起來的訪問，那麼它應該由發起訪問的DMA的Ｂ：Ｄ：Ｆ去表示。在應用程序中，能夠經過出發一條特殊的TLP，而後根據報文協議，來提取它的B:D:F，進而獲得它的ReqID。　一旦出現這種ReqID沒法探測的狀況，須要檢查用到的bar2/bar3或者bar4/bar5的基地址寄存器設置是否正確，檢查它的方法也是判斷bar的基地址寄存器的值是否和ＢＩＯＳ分配的地址一致。

４、用在地址轉換的bar size不夠大

受限於BIOS和ＥＥＰＲＯＭ設置，用做地址轉換的bar size是固定的，對於實現全系統內存共享或者大地址互相訪問的應用而言，這個地址窗口可能過小。爲此，就須要把地址調大。

首先，這須要ｂｉｏｓ給pci設備分配地址空間的時候，　可以支持足夠大的空間範圍，爲此，須要確保ＢＩＯＳ裏一些相關的設置已經使能，以筆者手中的ｂＩＯＳ爲例，它就須要使能56T以上的PCI地址空間，以下圖所示意：

其次，還須要修改用做地址轉換的bar的setup寄存器的值，這就須要查找手冊，根據寄存中bitmap和mask的設置，來設置足夠大的地址空間。須要注意的是，這個地址也不能超過BIOS所能支持的最大地址空間，不然極可能致使在系統pci emulate的時候由於沒法分配到足夠的地址空間而hang住。若是在某組地址轉換寄存器上沒法實現窗口擴大的話，能夠嘗試其餘地址窗口。好比筆者手上的bar2/bar3的窗口大小隻有1M，可是經過觀察/proc/iomem的輸出，能夠看到bar4/bar5的窗口足足有8G:

380000000000-383fffffffff : PCI Bus 0000:00

383c00000000-383e001fffff : PCI Bus 0000:04

  383c00000000-383e001fffff : PCI Bus 0000:05

    383c00000000-383e001fffff : PCI Bus 0000:06

      383c00000000-383dffffffff : 0000:06:00.0

      383e00000000-383e000fffff : 0000:06:00.0

加載對應的NTB驅動後，果真也能看到這個大窗口：

[86764.073933] LPC6500_NT:    Resource 01

[86764.073935] LPC6500_NT:      Type     : Memory

[86764.074004] LPC6500_NT:      PCI BAR 2: 383E0000000C

[86764.074006] LPC6500_NT:      Phys Addr: 383E00000000

[86764.074008] LPC6500_NT:      Size     :   200000 (2048 KB)

[86764.074010] LPC6500_NT:      Property : Prefetchable 64-bit

[86764.074206] LPC6500_NT:      Kernel VA: ffffc90017700000

[86764.074208] LPC6500_NT:    Resource 02

[86764.074209] LPC6500_NT:      Type     : Memory

[86764.074279] LPC6500_NT:      PCI BAR 4: 383C0000000C

[86764.074281] LPC6500_NT:      Phys Addr: 383C00000000

[86764.074283] LPC6500_NT:      Size     : 200000000 (8388608 KB)

[86764.074285] LPC6500_NT:      Property : Prefetchable 64-bit

[86764.487186] LPC6500_NT:      Kernel VA: ffffc90017e81000

[86764.487189] LPC6500_NT: Using PCI BAR 0 (VA=ffffc90016c80000) ==> PLX regs

根據上面的分析能夠看到，NTB調試過程當中，可能會碰到各類奇怪的問題，但萬變不離其宗，只要把握住了NTB地址轉換和數據傳輸的原理，總不難逐層分析出問題的根源，找到對應的解決辦法。