Memory DMA(PLX PEX 8733)运行一段时间后出现奇怪的src addr是否正常?

Memory DMA(PLX PEX 8733)运行一段时间后出现奇怪的src addr是否正常?,memory,linux-device-driver,dma,pci-e,Memory,Linux Device Driver,Dma,Pci E,我对DMA(PEX 8733)驱动程序传输的处理感到好奇,并使用kzalloc获得一个buff来观察正在运行的DMA描述符表 根据DMA规范,描述符格式如下: 当我开始观察时,结果是 (顺序为dw0、dw1、dw2、dw3)或预期的示例2 预期示例2: DMA Descriptor Entry 0, (80003c66, 3890, 74ea046c, fff4028e) DMA Descriptor Entry 1, (c000042e, 3890, 74ea0048, fff4024e)

我对DMA(PEX 8733)驱动程序传输的处理感到好奇,并使用kzalloc获得一个buff来观察正在运行的DMA描述符表

根据DMA规范,描述符格式如下:

当我开始观察时,结果是 (顺序为dw0、dw1、dw2、dw3)或预期的示例2

预期示例2:

DMA Descriptor Entry 0, (80003c66, 3890, 74ea046c, fff4028e)
DMA Descriptor Entry 1, (c000042e, 3890, 74ea0048, fff4024e)
DMA Descriptor Entry 0, (80007c0e, ffff3890, 65da046e, fffc04ee)
DMA Descriptor Entry 1, (c000042e, ffff3890, 65da0040, fffc00c0)
DMAR: DRHD: handling fault status reg 402
DMAR: DMAR: [DMA Read] Request device [01:00.2] fault addr fffc0000
DMAR: [fault reason 06] PTE Read access is not set
经过一段时间(大约2小时),结果显示:或意外示例2

意外示例2:

DMA Descriptor Entry 0, (80003c66, 3890, 74ea046c, fff4028e)
DMA Descriptor Entry 1, (c000042e, 3890, 74ea0048, fff4024e)
DMA Descriptor Entry 0, (80007c0e, ffff3890, 65da046e, fffc04ee)
DMA Descriptor Entry 1, (c000042e, ffff3890, 65da0040, fffc00c0)
DMAR: DRHD: handling fault status reg 402
DMAR: DMAR: [DMA Read] Request device [01:00.2] fault addr fffc0000
DMAR: [fault reason 06] PTE Read access is not set
我无法实现dw1在源地址的高字节中有
0xffff

我是否误解或错过了DMA描述符的某些内容

我不确定与高src addr相关的潜在问题(附加消息),但它在DMA运行一段时间后出现

其他消息:

DMA Descriptor Entry 0, (80003c66, 3890, 74ea046c, fff4028e)
DMA Descriptor Entry 1, (c000042e, 3890, 74ea0048, fff4024e)
DMA Descriptor Entry 0, (80007c0e, ffff3890, 65da046e, fffc04ee)
DMA Descriptor Entry 1, (c000042e, ffff3890, 65da0040, fffc00c0)
DMAR: DRHD: handling fault status reg 402
DMAR: DMAR: [DMA Read] Request device [01:00.2] fault addr fffc0000
DMAR: [fault reason 06] PTE Read access is not set

我不能理解你的结果。您说观测值的顺序为dw0,1,2,3,但在“预期”输出中,dw0始终为0,这意味着(根据您链接到的格式规范)传输大小为0,并且描述符有效位从未设置。我遗漏了什么?另外,如果你能将文本粘贴到你的问题中,而不是提供文本图像的链接,对读者来说会更方便。谢谢@GilHamilton回复和建议。@GilHamilton是的,在示例1中,条目实际上是无效的,传输大小为0。我发现预期的和意外的示例1并不好。因此,我添加了一个例子2,用一种清晰的方式来演示这个问题。源地址的高位字节在意外条目中为
ffff
。这似乎不正确(理论上是可能的,但这是一个非常高的内存地址)。因此,问题在于它是如何变成这样的。如果没有更详细的信息,我怀疑是否有人能在这里帮助你。