【64】事情也许没有想的那么复杂，大道至简，再谈AER

  在验证某芯片的AER功能时，突然发现RootPort的AER上报功能是正常，但是RootPort下面的网卡的出现PCIe错误时，竟然没有触发AER中断。

  当时心里想，不会是芯片问题吧。

（1）网卡的aer status 比特置1了，但是网卡没有发出error message？

（2）网卡发出的error message在PCIe链路上丢了？

（2）网卡发出的error被CPU丢了？

  于是看了下网卡芯片的配置空间，和错误上报相关的寄存器都是正常的，难道是网卡有什么特殊寄存器控制error message上报或者CPU把error message给丢了........越考虑越复杂。

  后来只能把整个链路上的配置空间都导出来看看，不得不说dump regs，然后用beyondcompare比较真是个好办法，发现竟然是RootPort的bridge ctrl 寄存的SERR bit没有置1。

这个bit是用来控制转发下游设备发送的error message的。

注意bridge ctrl的 SERR和cmd reg的SEER是两码事，该比特在aer 路径上的地位可以参考：

【58】PCIe错误处理机制是如何工作的_linjiasen的博客-CSDN博客

SERR# Enable - See Section 7.5.1.1.14 . This bit controls forwarding of ERR_COR, ERR_NONFATAL and ERR_FATAL from secondary to primary

  如此简单的问题，差点选择了一条不归路。等等，突然想起来了，很多年前，自研AER service的时候已经发现了这个问题，当时看过kernel driver确实存在这个问题，导致下游设备的error message无法上报给OS。这么多年过去了，这个bug不会还没有修复吧。于是，把最新kernel pull下来，发现竟然在5.1才修复了这个bug。kernel的AER果然是为了通用性牺牲了太多功能，不过这已经是kernel作为通用型框架来说的最优解了，搞笑的是很多公司竟然以为这也是最优解，最终把工业产品做成了玩具。

Re: [PATCH] PCI: Enable SERR# forwarding for Type-1 PCI devices - Bjorn Helgaas