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:D:F,如果是由cpu发起的访问,那么它通常用北桥root
cmplex的B:D:F来表示,如果是DMA发起来的访问,那么它应该由发起访问的DMA的B:D:F去表示。在应用程序中,可以通过出发一条特殊的TLP,然后根据报文协议,来提取它的B:D:F,进而得到它的ReqID。 一旦出现这种ReqID无法探测的情况,需要检查用到的bar2/bar3或者bar4/bar5的基地址寄存器设置是否正确,检查它的方法也是判断bar的基地址寄存器的值是否和BIOS分配的地址一致。

4、用在地址转换的bar
size不够大

受限于BIOS和EEPROM设置,用作地址转换的bar
size是固定的,对于实现全系统内存共享或者大地址互相访问的应用而言,这个地址窗口可能太小。为此,就需要把地址调大。

首先,这需要bios给pci设备分配地址空间的时候, 能够支持足够大的空间范围,为此,需要确保BIOS里一些相关的设置已经使能,以笔者手中的bIOS为例,它就需要使能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地址转换和数据传输的原理,总不难逐层分析出问题的根源,找到对应的解决办法。

时间: 2024-10-14 05:17:33

NTB调试常见问题指南的相关文章

掌握VS2010调试 -- 入门指南

Reference from : http://blog.csdn.net/kingzone_2008/article/details/8133048 1 导言 在软件开发周期中,测试和修正缺陷(defect,defect与bug的区别:Bug是缺陷的一种表现形式,而一个缺陷是可以引起多种Bug的)的时间远多于写代码的时间.通常,debug是指发现缺陷并改正的过程.修正缺陷紧随debug之后,或者说二者是相关的.如果代码中存在缺陷,我们首先要识别造成缺陷的根本原因(root cause),这个过

NTB EEPROM设置与跨节点数据传输

NTB EEPROM设置与跨节点数据传输 双控双活系统中除了需要监测系统状态的心跳之外,还需要能够跨节点传输数据的通道.PCIE非透明桥(NTB)由于其基于标准的PCIE规范,软件依赖少,速度快,配置简便,受到许多人的青睐.基于PCIE NTB进行跨节点数据传输的原理很简单,如下图所示意: 较之于普通的PCIE/PCI设备的配置空间寄存器,NTB上多了bar2/3,bar4/bar5的地址转换寄存器,本地节点发送过来的命中bar2/bar3或者bar4/bar5的TLP的地址高位会转换成相应的地

Qualcomm平台camera调试移植入门

1  camera基本代码架构 高通平台对于camera的代码组织,大体上还是遵循Android的框架:即上层应用和HAL层交互,高通平台在HAL层里面实现自己的一套管理策略: 在kernel中实现sensor的底层驱动.但是,对于最核心的sensor端的底层设置.ISP效果相关等代码则是单独进行了抽离,放在了一个 daemon进程中进行管理: 图1 Qualcomm平台camera代码架构简图 由于高通把大部分具体的设置及参数放到了daemon进程中,所以在kernel部分只是进行了V4L2的

android TP驱动移植调试笔记(转)

1. 添加I2C 设备 TP 一般采用的是I2C 作为数据和命令接口,所以TP 驱动也可以归类为I2C 驱动.TP驱动的主要逻辑不在这里,但是了解了Linux 的I2C 体系架构,就可以对整个驱动流程有了 更加清晰的认识,但这里不详细展开讨论I2C 的体系架构,只围绕怎么移植开发TP 驱动展开讨论. 在板级文件中,也就是瑞星微的代码文件board-rk30-sdk.c 中,实例化一个i2c_board_info结构体,该结构抽象描述一个具体的i2c 设备,然后将该实例添加到__i2c_board

【Windows Service】Windows Service在Visual Studio中安装、调试

目录结构: contents structure [-] 创建Windows服务 配置 安装Windows服务 在Visual Studio中调试 常见问题 最近写了一个TCP连接的程序,由于这种通信协议不同于HTTP协议,因此还不能部署到网站上面,于是就用到了Window服务.接下面笔者介绍一下在Visual Studio中如何安装.调试Windows服务.笔者的Visual studio版本为2012,window版本为win7. 1.创建Windows服务 这时候点击“启动”按钮,会提示我

JavaScript - 收藏集 - 掘金

Angular 中的响应式编程 -- 浅淡 Rx 的流式思维 - 掘金第一节:初识Angular-CLI第二节:登录组件的构建第三节:建立一个待办事项应用第四节:进化!模块化你的应用第五节:多用户版本的待办事项应用第六节:使用第三方样式库及模块优化用第七节:给组件带来活力Rx--隐藏在 Angular 中的利剑Redux你的 A... Electron 深度实践总结 - 前端 - 掘金思维导图 前言: Electron 从最初发布到现在已经维护很长一段时间了,但是去年才开始慢慢升温.笔者个人恰好

kuma 学习三 组件说明

当前官方已经提供了两种可选的运行模式 通用模式 kubernetes 模式 kuma 组件说明 kuma-cp kuma 的控制面板 kuma-dp kuma 的数据面板 enovy 提供sidecar 服务的 kumactl 命令行与kuma-cp 通信的 kuma-injector 只有kubernetes 环境需要,用来自动处理容器的sidecar 通用模式 对于通用模式,需要依赖一个后端进行状态存储,官方当前建议的是pg 参考架构图 kubernetes 模式 需要依赖kuma-inje

网络安全学习资料汇总

一.Web security 1. <http权威指南>[图灵出品]:  深入理解web http/https协议 ,了解超文本传输协议是如何进行传输和编译的. 2. <javascript权威指南>:淘宝前端团队翻译,深入了解前端js变量,注释,函数,表达式等,学习xss必备书籍.还提及了jquery类库. 3. <xss跨站脚本攻击与防御>: 学习xss基础必备.也是目前国内唯一一本专门介绍xss技巧的书籍. 4. <白帽子讲web安全>:  阿里安全专

qualcomm platform camera porting

1  camera基本代码架构 高通平台对于camera的代码组织,大体上还是遵循Android的框架:即上层应用和HAL层交互,高通平台在HAL层里面实现自己的一套管理策略:在kernel中实现sensor的底层驱动.但是,对于最核心的sensor端的底层设置.ISP效果相关等代码则是单独进行了抽离,放在了一个daemon进程中进行管理: 图1 Qualcomm平台camera代码架构简图 由于高通把大部分具体的设置及参数放到了daemon进程中,所以在kernel部分只是进行了V4L2的设备