BMC中USB问题分析定位和解决案例

USB 问题分析定位和解决案例

目录 ONTENTS

1. BMC部分分析总结
2. BIOS部分分析总结
3. 硬件部分分析总结

BMC部分分析总结

1. 问题发现过程及问题现象
2. 分析此类问题的方法
3. 如何找到该问题的复现规律
4. 该问题详细分析过程之如何排除软件问题
5. 该问题详细分析过程之如何确认是硬件问题
6. USB其余问题汇总

1. 问题发现过程及问题现象

此问题发现过程：跑AC掉电测试
问题现象：
概率出现KVM上鼠标键盘不能用，Host端均正常。操作系统下用dmesg命令查看启动日志，报下图错
误，会不停的刷日志。number后的值会不停的变化

从上述现象可以得出以下结论：
1.此问题是概率性的
2.可以看出一直有USB设备被检测到，这个现象跟我们不停地插拔USB鼠标很像
的，然后看不出其他有用的信息了。
3.该机器跑AC lost一定可以复现此问题。（有利条件）

2. 分析此类问题的方法

此问题最大的特征就是概率性出现。
针对概率性问题，最重要的就是找到稳定复现问题的方法，因为能复现的问题都是可以解决
的。
找到稳定复现问题方法的好处：
1.问题稳定复现之后，可以加调试打印，跟踪问题，分析出异常的原因和代码流程错误的位
置。
2.修改代码之后，可以验证问题是否被修复
概率性问题，处理方法一般有正面复现法和猜想法。
正面复现法：根据机器每次出现报错时，对机器所做的操作以及相应的现象找到复现规律，
提高复现概率。此方法一般针对可以大概率复现的问题。
猜想法：根据收集到的信息猜测有可能出现问题的地方，然后在这些地方故意构造错误代码
进行测试，查看报错现象是否一致。使用此方法，最好的情况可以让概率性问题成为必现问
题。

3. 如何找到此类问题的复现方法

寻找概率性问题的复现规律，需要对机器做各种尝试，收集各种现象，然后找到问题出现与消失跟什么
操作存在关系，从而找到复现规律。因为能复现的问题基本都是可以解决的，寻找问题的复现规律很重要。
对机器做各种尝试，发现以下规律：
现象1：该机器跑AC lost脚本，此问题一定会出现，时间有长有短。
现象2：该机器出现上述问题后，拔掉电源线后，当主板上LED灯全部灭掉之后，立即插上电源线，该问题大概率不会消失，存在消失的情况。
现象3：如果机器已经报usb 错误，拔掉电源线，等待五分钟后再插上电源线，此问题极小概率会出现。
现象4：如果机器正常运行，无报错，拔掉电源线，待电源灯灭掉之后插上电源线，该问题概率性出现。
现象5：该机器出现上述问题后，在KVM页面重启电源、重启BMC或更新BMC版本，该问题不会消失。

根据上面的5个现象可以得出以下结论：
1.出现问题的时候，操作BMC，此问题不会消失。
2.对电源进行操作，该问题会出现，也会消失。
这里可以大概猜测此问题的出现或者消失跟开关电源存在很大的关系。
然后根据猜测不停的做开关机尝试。由于进出机房插拔电源线太麻烦，我选择在KVM页面不停的关机（立即关闭按钮）和开机（电源开启按钮）。关机和开机动作之间的等待时间有长有短，中间并夹杂着开关KVM的动作（在USB可以正常使用的时候，开关KVM可以触发USB的一些操作）。经过多次尝试，发现关机之后等待30秒左右，并在这30秒之内开关KVM一次，可以大概率复现上述问题。按照这个方法，最快能在五分钟之内复现出问题，最慢基本不会超过二十分钟。这个概率已经很高了，已经可以满足分析问题的条件。

4. 该问题详细分析过程之如何排除软件问题

根据系统下面的启动日志信息，可以有两个方向：
一是软件问题
二是硬件问题
如果是硬件问题，也需要通过分析软件，先排除软件问题，然后找证据证明是硬件的
问题，所以首先分析软件问题，但是不能放弃对硬件问题的怀疑。
首先需要找到怀疑点，然后在怀疑的地方加调试信息，不然复现之后，什么有用的信息
都获取不了。
如果是软件问题，问题应该会出现在数据交互、USB设备初始化和hub初始化这三个地
方。

判断是否是USB设备数据交互的问题，只需要在BMC串口下查看USB拓扑图即可确定。在复现此问题的机器上，进入到BMC串口下查看USB拓扑图，结果如下：
正常运行机器，USB拓扑图如下：

异常机器，USB拓扑图如下：

结论：此问题不是USB设备数据交互的问题。因为USB拓扑显示USB设备未成功初始化，根本就不会存在数据交互的可能性。现在就只剩下USB device初始化和hub初始化的问题。

由于USB device的初始化过程在hub初始化完成之后进行的，所以先分析hub是否成功初始化。
分析方法：
在机器报错的时候，去BMC的串口下用regmemapp命令去读取USB hub相关寄存器中的值。
正常运行机器 USB寄存器值，如下图：

现象1：对比正常和异常机器的两组寄存器中的值，可以发现异常机器的0x1e6a0004地址的寄
存器的值是全0，该寄存器的低7位表示Root function device address，正常情况下是非零的。

现象2：状态寄存器0x1e6a0024值的第31位为1，表示hub处于挂起状态，正常应该为0。
异常机器 USB寄存器值，如下图：

结论：根据上面的两个寄存器的值可以判断出USB hub初始化失败。

接下来需要分析hub为什么会初始化失败，需要分析hub初始化流程，需要去看
hub的驱动代码。代码在ast_usbhub.c文件中。查看驱动代码，需要先查看init入口函
数，此代码在文件最后的module_init函数中。

代 码 中 注 册 了 一 个 中 断 处 理 函 数ast_usbhub_irq_handler，usb hub接收到的所有中断信号都进入此函数进行处理。

由于hub的初始化大部分操作都是在中断处理函数中完成的，所以需要重点关注中断寄存器的状态
。由于中断信号的处理过程很快，中断状态寄存器的值很快就会被清零，所以用（regmemapp -r -s
0x1e6a0000 -e 0x1e6a00ff）命令获取到的中断状态寄存器的值在什么时候都是一样的。根本不能反映
出中断信号的变化过程，所以需要在代码中添加打印信息查看hub的初始化过程，找出异常的位置。
经过分析代码之后，刚开始以为BMC给HOST的应答部分出了问题，只在SETUP_ACK的中断信号处理部分加了打印信息。经过复现之后，发现出问题的机器根本没有产生这个中断信号，正常机器会有该中断。

接下来在所有中断信号的处理部分都添加了打印。验证发现BMC下面的中断信号一直在bus
reset、resume、suspend这三个状态之间不停的切换。正常的情况是在BUS reset、resume这两个中
断之后，会出现EP0 Setup Data Arrives中断信号过来，然后进入setup阶段。经过分析hub中的bus
reset、resume中的代码和各种调试打印之后，依然没有发现这部分代码可能存在的问题。这里可
以知道USB总线被挂起，但是不知道为什么会被挂起。

分析到这里的时候，就进入瓶颈期了，然后做了下面的尝试：
a：找硬件量信号，只能从信号中看出来usb总线在初始化的时候会被挂起，由于没有逻辑分析仪，
不能看出信号中的数据是否有问题。

b：怀疑是在应答的时候数据出错了或者内存中数据被修改了，想办法进行KDB追踪，搭建好KDB追
踪的运行环境之后，由于进入KDB之后用户进程全部停掉了，只能去查看当前内存和寄存器中值，不能单步调试，不能获取到什么有用的信息，此方法行不通。然后仔细梳理代码流程，发现reset、resume阶段根本不存在应答过程，所以排除应答错误的可能性。

c：求助AMI，各种修改hub的配置，改变hub的初始化流程，问题依然存在。

d：找BIOS冲讨论此问题，并查看BIOS中与hub初始化相关的代码，未发现异常。

经过上面的各种尝试之后，依然没有找到好的想法。
在这里我怀疑硬件有问题，但是没有证据将问题的方向指向硬件。
需要找到新的突破口！！！

我在BMC中的代码中加打印打出中断状态寄存器的值时，突然想到在BIOS的代码中也加打印打出寄存器的值。
经过验证之后发现：USBhub的初始化在Power阶段就失败了。BMC将设备唤醒之后，BIOS并没有获取到有效设备存在的状态，所以在3ms之后就会将总线挂起。由于这些状态寄存器的置位和清除并不需要软件去参与，都是芯片内部实现的。这里就将问题的方向指向了硬件。

USB总线挂起的原理：
在USB系统中，正常状态下hub或root hub会一直周期性地发送SOF包(Start Of Frame，全速USB每1ms发送一个，高速USB则是125µs发送一个)。根据USB协议，如果USB线上一直处于空闲(Idle)状态超过3ms，设备应该把它当作一个挂起(Suspended)信号。

如右图所示：检测挂起信号（即3ms内USB总线上没有信号）是由硬件定时器来完成的，根本不需要软件参与。

5. 该问题详细分析过程之如何确认是硬件的问题

经过上面的分析和定位，所有的信息都指向了硬件。此问题并不像普通的单端信号，可以通过信号直
接看出信号是否有问题。USB信号是差分信号，没法直接看出信号问题，这里需要找硬件相关人员一起配合验证。
这里找经理讨论之后，经理怀疑有可能是虚焊或者芯片的问题（芯片出现问题的可能性比较小），然
后将板子拿回工厂烘烤。烘烤回来之后还是有问题存在。在烘烤期间，工厂老化的设备出现了下图中的问题：

查看Linux 内核源码和在百度上搜索之后，发现报（err -71）问题与电源或者信号相关的。然后跟经理交流之后，决定用我一块好的板子剪掉一根信号线做实验试试看。剪掉D-信号线之后，该问题成功复现。

内核中71号error代表的含义，如右图：

根据这个经验，怀疑有可能是信号不稳定，或者虚焊造成的。跟经理交流之后，经理决定从外面的USB口单独引出两根信号线。在单独引出信号线的机器上，经过一天的复现验证，该问题未再出现。根据之前的复现经验，正常情况下在半个小时之内会出现。
在这里得出的结论是此问题是硬件问题，经理给出的结论是信号问题。量USB眼图发现信号质量确实不太好。BIOS修改调信号相关参数后，此前必现的机器上，已无该问题。工厂老化出现这个问题的机器在更新调整过USB眼图的BIOS版本之后，该问题消失。由于此问题是概率性问题，目前只能认为调整过眼图的版本降低了此问题出现的概率，还不能认为是彻底解决此问题。还需要长期的测试和验证。

6. USB其余问题汇总

问题1：
现象：KVM上鼠标键盘不能用，操作系统下报（err -71） 如下图所示：

问题2：
现象：KVM上鼠标键盘不能用，操作系统下报错，如下图所示：

使用调整过眼图（寄存器值为5531）的BIOS版本上成功复现，报错如下：

现象和报错与工厂出错的机器完全一致，故该问题与问题1也是信号问题导致。

问题3： (用猜想法复现问题案例)
现象KVM上鼠标键盘不能用，操作系统下报（err -19）如下图所示：

复现方法：故意在代码中增加不满足规范或者错误代码，迫使此问题出现。
a. 该问题的原因已经找到，是BMC发给host的数据有问题，目前没有机器能复现出该问题
b. 此问题出现的原因是操作系统只支持31个ports，如果获取到的hub描述符中的ports数量超过31就会报（err -19）错误
c. 在代码中将hub 描述符中的bNbrPorts值修改为32，此问题成功复现
d. 正常情况下，host 从 BMC 获取hub描述符时，hub描述符相关数据都会先拷贝到DMA buf中，在模拟此问题时，使用的方法是概率性将拷贝过程屏蔽掉，DMA就会获取DMA buf中旧的数据，经过多次重启电源，该问题复现。
e. 目前由于没有机器可以正面复现这个问题，初步怀疑是 DMA数据传输过程中出错或者信号问题导致该数值不对，已经在DMA进行数据传输的时候添加优化代码和日志跟踪代码，如果再出现此类问题，就能知道是否是数据传输出错或者其他什么原因。由于信号问题后期会得到优化，预计此问题应该不会再出现。

内核中源码，如右图：

BIOS部分分析总结

1. USB问题现象分析
2. 原因分析及验证
3. 信号调整验证
   

1. USB问题现象分析

USB 问题具有如下特点：
1）某些主板才出现USB 问题报错；
2）出现问题的故障主板呈现概率性复现的特点；
3）概率可高可低，与主板个体有关；
4）故障现象以不同表象呈现在BIOS阶段和OS阶段；

依据问题现象分析可能的原因：
1）USB代码部分某些参数处于临界值，导致在不同主板上出现不同表现；
2）主板生产制程有缺陷或者Layout走线有瑕疵；
3）信号质量不符合要求；

2. 原因分析及验证

可能原因之一：
USB代码部分某些参数处于临界值，导致在不同主板上出现不同表现；
调查验证如下：
经查询，在USB Hub出现异常进入挂起状态的代码中，BIOS对下游设备主要为USB端口开启、关闭、重启操作，控制器与下游设备的Training由芯片控制器与下游设备自协调完成。代码中在开启、关闭、重启之间，适当添加延时时间，确保芯片和下游设备自协调的时间是充足的，验证结果无效。结合相同主板其他端口设备，代码无需修改即可完成设备识别连接，可得结论代码参数临界值的可能原因被排除。下游设备代码部分由BMC查验也未能找到原因。

可能原因之二：
主板生产制程有缺陷或者Layout走线有瑕疵；
调查验证如下：
Layout走线部分经过硬件查验，设计上不存在瑕疵；生产制程上的缺陷无法查验，暂时不在深入调查；

可能原因之三：
信号质量不符合要求；
调查验证如下：
此问题在开机阶段和系统下，均有出现，而系统下驱动程序，经过大规模大范围的充分验证，成熟度很高，概率性出现问题的可能性更低。需要硬件量测信号眼图情况。经过测试，眼图有质量较差，有极大可能是信号质量较差导致的问题。

3. 信号调整验证

调整USB信号眼图：
信号控制主要通过预加重和预减重方式来优化调整。

调整USB信号眼图：
经过多次测试，找到一组最优值，6/6/1/1，眼图状况较好。将信号调好的BIOS，烧录在多片问题主板进行验证，问题均得到解决，最终确定为信号质量问题。

硬件部分分析总结

1 所做的硬件试验

鉴于BMC同事的分析，硬件这边做了3个实验，来佐证BMC同事的分析：
1.拿之前OK的单板，把USB信号(BMC和PCH通信）：如下所示，USB2_BMC_1_DN割断。


经过验证发现，USB KVM都不能使用，系统下面同样打印-71代码。
跟之前出现USB BMC 同样现象。

2 BMC芯片重新焊接

第2个试验：就是怀疑BMC USB的信号没有焊接好，导致出现USB 的问题。后来，请生产同事：
把报错单板拿到一博，烘烤后。重新用BGA焊台对BMC焊接。
当单板拿回来之后，重新验证，发现出现同样的现象。还是出现出现USB 的问题，在KMV下面
，USB键盘，鼠标不能使用。

3.远端USB飞线验证

第3个试验：进行BMC USB硬连线到另外一个PCH USB PORT
即：
1.原来的PCH到BMC USB PORT进行割断，然后把Rear I/O的一个USB PORT连接到BMC的PORT A，如下图所示;

2.进行验证，发现第一天没有出现错误，第2天也没有出现BMC USB的问题；
产生疑问：是否USB信号有问题。同时，把这个情况也发邮件给到ASPEED，寻求帮忙。

测试验证一

之前，有记得测试过PCH到BMC的USB信号，当时测试信号质量还可以。主要是在BMC附件测试（PCH发送，BMC接受）；而没有再PCH端测试。这次让BMC同事，根据AST2500规格书中的USB EYE测试流程，分别在BMC附近和USB附近，进行了测试，其信号质量如下：

上图中，中间是BMC附近测试（PCH发送，BMC接收）测试波形，右图是PCH附近测试（BMC发送，PCH接收）测试波形。

测试验证二

把测试波形发送给到ASPEED分析后，原厂技术支持直接回复邮件，让我们调试PCH USB Setting.

ASPEED给了2组值：1611，6611。
ASPEED给出的这些寄存器值，在Intel给出的文档：564421中：564421-c620-chipset-hsio-
tune-guide-564421r1.pdf中有讲解如何调试这些寄存器，之前BIOS也有调试过，只是参数值
不是太合适。

测试验证三

根据ASPEED给出的调试值，请BIOS工程师进行了修改，进行测试。波形如下：

1.6611测试值；
BMC附近测试

PCH附近测试

2.1611测试值：
BMC附近测试

PCH附近测试

测试对比

根据ASPEED给出的调试值，请BIOS工程师进行了修改，进行测试。波形如下：

测试总结

1.后来请BIOS测试人员又测试了很多组寄存器值，发现只有6611的眼图质量最好；
2.把测试结果发给ASPEED技术支持确认之后，他认为调整后的眼图质量优化了很多，还让我们确认在系统下面是否还有报错。另外，PCH到BMC之间的USB走线长度最好要超过4Inch；这个也是在Intel PDG中有写这个要求。之前USB长度为：3.7Inch，后来C版本为：4.2Inch.
3.经过内蒙和无锡返回的单板测试验证，发现烧录修改USB寄存器后的BIOS，原来有报错的单板，不再报USB的问题。

后面：
1.关于USB这些非特高速信号要严格遵循Intel的PDG Guide，避免经验造成错误；
2.这些USB信号，后续需要按照BMC GUIDE里面测试，不仅仅要在BMC附近测试，且在PCH附近都要进行测试；

---

BMC AST2500/AST2520 下载

BMC AST2500/AST2520数据手册下载