本文主要是介绍【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
这篇关于【64】事情也许没有想的那么复杂，大道至简，再谈AER的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
