高通平台PCIE EP模式log丢失问题

高通平台PCIE EP模式log丢失问题

1 问题背景
2 问题分析

2.1 对比USB

2.1.1 Logtool优化
2.1.2 Device mhi与fs对比

2.2 优化方案

2.2.1 Diag系统优化
2.2.2 Host mhi优化

3 最终成果

1 问题背景

高通5G模组如SDX55SDX62SDX65SDX72SDX75等支持pcie ep模式。会通过pcie与host（如MT7621IPQ5018IPQ6018等）连接作为CPEODU等使用。在客户使用场景和研发debug时，均会出现各种问题，需要抓取qxdm log用于问题的分析。

当前在linux上使用的是logtool工具抓取log并保存到host，或直接透传与win qxdm工具连接抓取log到win上。这两种方式在pcie模式下均存在严重的log丢失问题，严重阻塞客户问题的分析。

Log丢失情况说明：如cfun01操作，让模组重新注网，我们仅可以抓到鉴权请求log，其他如鉴权响应、网络注册请求响应、pdu建立请求响应等均已丢失：

2 问题分析

2.1 对比USB

同样的上位机环境（如IPQ4019），不同的连接方式（PCIEUSB），通过抓log对比分析，发现usb下log不存在丢失问题，而pcie下log丢失严重。

初步我们怀疑是host cpu对于usb和pcie数据处理能力的差异导致，通过统计两种模式下diag口数据poll次数，发现存在很大的差异，usb每三秒poll次数在1000次左右，而pcie模式下每三秒poll次数在10000次左右，是usb的十倍：

Poll次数越多，越依赖cpu的处理能力，这可能也是pcie log丢失严重问题的关键。

2.1.1 Logtool优化

从上面我们知道pcie模式下poll次数每秒4000次，那也意味着写文件也是4000次。由于logtool从diag口读取数据包，再写到文件中，这两个动作在同一个线程中，属于串行，效率较低，依赖于cpu的io处理，为了避免读写任一操作较慢导致阻塞，进而数据包丢失，我们特对logtool做出如下优化：
（1） 拆解读写流程为两个线程处理，避免阻塞
（2） 增加链表来管理数据包，减少数据包丢失

修改后验证有所改善，但未能彻底解决问题。

2.1.2 Device mhi与fs对比

我们分别在模组PCIE（mhi）和USB（fs）串口层加数据包大小log打印，发现在diag层数据包发送时都是几十个字节，mhi层收发也是几十个字节；而fs层收发是几千个字节。
Diag层：

Mhi层：

fs层：

对比fs和mhi层，均没有对于数据有聚包操作，数据包从io收到就已经是有差异的，因此需要从diag系统中去寻找差异。

2.2 优化方案

2.2.1 Diag系统优化

diag在端口初始化时会分别注册pcie和usb的回调函数：

pcie和usb写函数中最终调用的都是dm_send_flow:


dm_send_flow按照流程最终会调用watch_submit_aio，然后通过io的方式将数据写到fs或mhi。在watch_submit_aio中对于数据进行了是否聚包操作：

而是否聚包取决于w->use_iovec是否设置，在diag系统中usb设置了该属性，而pcie是没有的：

这就符合我们看到的现象：在fs中收到了几千个字节的数据包，而mhi仅有几十个字节。基于这个分析，给pcie也增加聚包：

经测试，数据在mhi层也可以达到几千字节，最大不超过16k的数据包：

但由于mhi层各端口设置了ring buffer限制，导致数据大于ring buffer时会直接丢弃，因此同步修改mhi diag通道ring buffer大小，并去掉trb限制：


验证还是提醒大于tre len。

2.2.2 Host mhi优化

经分析是由于host mhi驱动diag通道ring buffer限制为2k，导致device侧数据无法发送大于2k的数据，否则会导致host crash：

修改为与device端mhi匹配的ring buffer大小16k。

到这里，基本上所有的分析就结束了，让我们看下最终的成果。

3 最终成果

ota log抓取完整，整个注册流程完善，与usb抓取log无差异。目标达成。

每三秒poll次数，由之前的10000次左右降为800次左右：