【23】share中断引发的教训和PCIe DPC代码的bug

港控/mmm° 2022-02-03 00:15 339阅读 0赞

最近在验证某款芯片的DPC和热插拔功能，发现在暴力拔出和插入SSD时，dpc\_irq都会被调用到，但是DPC Status又显示没有触发DPC，一开始以为是芯片bug。后面查询了一下share中断的东西，发现是老版本dpc的代码的bug。（说到这里就汗颜了，以前在某不止是500强搬砖时也遇到一样的问题—中断服务函数被调用，然后status reg为0，有个打印，会频繁打印。当时没有搞清楚share中断的机制，就直接把打印删除了，修改方式倒是没有问题，只是为了快速消灭问题单，没有搞清楚share中断）。

话题回到现在的场景，由于我使用的CPU支持AER、DPC和hotplug功能，OS会注册AER中断函数、DPC中断服务函数、hotplug中断服务函数，并且都是使用的share中断。当我暴力拔出SSD时，data link laer从active跳转到inactive，产出data link active change中断，插入SSD时，会有presence change 中断。这个时候OS会调度CPU端口注册的三个中断服务函数。  
低版本的dpc\_irq代码有bug，只是判断DPC status不为全1并且不0就认为DPC中断触发了，而恰巧DPC STATUS的bit12-8默认值是1 1111b。因此，拔插SSD 时，我们可以看到打印出DPC STATUS reg为0x1F00。  
关于DPC的代码的bug，在高版本OS和下面补丁中已经修复  
https://patchwork.kernel.org/patch/10112467/  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpbmppYXNlbg_size_16_color_FFFFFF_t_70]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpbmppYXNlbg_size_16_color_FFFFFF_t_70 1]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpbmppYXNlbg_size_16_color_FFFFFF_t_70 2]  
关于share中断问题，stack overflow有明确的解释  
https://stackoverflow.com/questions/14371513/for-a-shared-interrupt-line-how-do-i-find-which-interrupt-handler-to-use?answertab=active\#tab-top

https://stackoverflow.com/questions/4732570/return-value-of-interrupt-handlers-in-linux-kernel  
The kernel will sequentially invoke all the handlers for that particular shared line.

Exactly. Say Dev1 and Dev2 shares the IRQ10. When an interrupt is generated for IRQ10, **all ISRs registered with this line will be invoked one by one.**

In our scenario, say Dev2 was the one that generated the interrupt. If Dev1’s ISR is registered first, than its ISR (i.e Dev1’s ISR) only called first. **In that ISR, the interrupt status register will be verified for interrupt. If no interrupt bit is set (which is the case, cause Dev2 raised the interrupt) then we can confirm that interrupt was not generated by Dev1 - so Dev1’s ISR should return to the kernel IRQ\_NONE - which means:“I did not handled that interrupt”, so on the kernel continues to the next ISR (i.e Dev2’s ISR), which in turn, will indeed verify that its corresponding device generated the interrupt, thus, this handler should handle it and eventually return IRQ\_HANDLED - which means:“I handled this one”.**

See the return values IRQ\_NONE/IRQ\_HANDLED for more information.

How does the handler know that the corresponding device issued the interrupt or not ?

By reading the Interrupt status register only.

Is this information relayed through the interrupt controller that is between the devices and the processor interrupt line ??

I’m not sure about this. But the OS will take care of calling ISRs based on the return values from ISR.

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpbmppYXNlbg_size_16_color_FFFFFF_t_70]: /images/20220203/44dcbb8694b84ab68beb026a5aafd019.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpbmppYXNlbg_size_16_color_FFFFFF_t_70 1]: /images/20220203/402b5c473adc4f069933ec60cd70c51e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpbmppYXNlbg_size_16_color_FFFFFF_t_70 2]: /images/20220203/c9e8faa72d0340e4805b97000d02e439.png