Felix

技术源于积累,成功始于执着! 个人邮箱:justlxy@mail.dhu.edu.cn QQ:1576109464

PCIe扫盲——PCIe错误源详解(一)

0
阅读(16142)

连载目录篇:http://blog.chinaaet.com/justlxy/p/5100057779


这篇文章来详细地分析一下各种错误源的产生原理,由于内容较多,因此分为两篇文章。第一篇介绍一下ECRC校检错误和Data Poisoning等;第二篇文章介绍事务(Transaction)错误、链路流量控制(Link Flow Control)相关的错误、异常的TLP(Malformed TLP)以及内部错误(Internal Errors)等。

  • ECRC

前面的文章中提到过,ECRC是可选的,主要用于包含有Switch的PCIe总线系统中。且只有支持AER的PCIe设备才有能力支持ECRC功能。配置软件通过检查配置空间,确认PCIe设备的某个功能(Function)支持ECRC后,可以通过向错误功能控制寄存器(Error Capability and Control Register)中的响应为写0或者1来禁止或者使能ECRC功能。

如果使能了ECRC功能,可以通过TLP包头中的TD(TLP Digest,ECRC也被称为Digest)为来标记当前的TLP是否使用ECRC,如下图所示。需要特别注意的是,如果TD为1(表示使用ECRC),但是TLP中却没有ECRC;或者TD为0,TLP中却包含了ECRC,则会被判定为TLP格式错误,即Malformed TLP错误。

image.png

ECRC是基于TLP的包头和数据(Header and Data Payload)计算的,接收端会重新基于这些内容计算并与收到的TLP中的ECRC(发送端计算的)作对比,如果不一致,则认为数据传输过程中发生了问题,数据被破坏了,进而产生ECRC校检错误。需要注意的是,在TLP包头中,有两位实际上是不参与ERCR计算的——Type域的bit0和EP位。这两位通常被称为Variant bits,且在ECRC计算的时候,这两位的对应位置始终被认为是1,而非使用实际的数值。

当接收端(Completer)接收到的请求(Request)TLP中存在ECRC校检错误时,接收端通常会选择不对该请求发送返回TLP(Completion),并将ECRC错误状态位(配置空间中的)置位。发送端由于长时间未接收到Completion,进而会产生Completion超时错误(Timeout Error)。而大部分发送端,会选择重新发送先前的请求Request。

当发送端(Requester)在发送完请求后收到了来自接收端返回的TLP(Completion)时,却发现该Completion TLP中存在ECRC校检错误,会将ECRC错误状态位(配置空间中的)置位。发送端可以选择重新发送先前的请求Request,还可以选择通过特殊功能中断(Function Specific Interrupt)向系统报告错误。

以上两种情况中,如果使能了错误消息报告功能的话,不可校正的非致命错误消息(Uncorrectable Non-fatal Error Message)会被发送至系统。

  • Data Poisoning(Poisoned Data or Error Forwarding)

Data Poisoning也被称为错误传递(Error Forwarding),指的是在已知TLP Data Payload被破坏(Corrupted)的情况下,该TLP仍然被发送至其他的PCIe设备。此时,该TLP包头的EP位(Error Poisoned)被置位为1,表明该TLP已经被破坏。如下图所示:

image.png

有人可能要有疑惑了,你既然都已经知道该TLP Data Payload被破坏了,为什么还要再将其进一步传递呢?实际上,这样做主要是针对某些特殊的应用的:

☆    便于发送端(Request)和系统分析错误:假设发送端(Request)向接收端(Completer)发送了读数据请求,接收端从某个内存设备中读取数据后通过Completion返回数据给发送端。但是在此过程中发生了错误,接收端(Completer)因此不向发送端(Request)返回Completion,则发送端只会产生Completion Timeout错误,却难以分析错误原因。如果接收端返回Poisoned Completion TLP给发送端(TLP包头中EP为1),则发送端至少可以确认接收端正确地接收到了其发出的请求(Request)。

☆    便于发现Switch(或其他桥设备)中的错误:假设TLP中的Data Payload是在Switch中被破坏的,采用错误传递的方式有助于发现该错误。

    有些应用允许接收存在错误的数据:比如实时的音频或者视频传输,其宁可接收到有些许错误的数据,也需要尽量保证数据传输的实时性。

    数据可能通过应用层恢复:有些应用可能采用了特殊的编码 ,该编码可以恢复某些被破坏的数据(如ECC可恢复1位的错误)。

需要特别注意的是,错误传递(Data Poisoning or Error Forwarding)只是针对TLP中的Data Payload是否被破坏,和TLP包头的内容无关。也就是说错误传递只是针对那些带有Data Payload的TLP的,如Memory、Configuration、I/O写或者带有返回数据的Completion。PCIe Spec没有定义对没有Data Payload的TLP,其TLP包头中的EP却为1的情况,应当如何处理。

注:需要注意的是,Poisoning操作只能在事务层进行。原因很简单:数据链路层和物理层在任何情况下,都不会检查TLP包头的内容,更不会修改TLP包头。