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设备驱动程序去解决。

2、NTB mailbox register无法传送数据

根据NTB的使用说明，一般而言，NTB的mailbox和doorbell寄存器用来在多个节点之间传递信息进而实现上层的同步。如果出现doorbell /mailbox寄存器读回来的数是0xffffffff的话，那么需要检查映射doorbell/mailbox寄存器的bar0/1的设置是否正确。方法是通过lspci读出bar0/1的值，检查它是否和BIOS给它分配的物理地址一致。

3、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地址转换和数据传输的原理，总不难逐层分析出问题的根源，找到对应的解决办法。

本文转自存储之厨51CTO博客，原文链接： http://blog.51cto.com/xiamachao/1794555，如需转载请自行联系原作者