首先-标题有点误导，因为RCU停顿可能只是问题的征兆。
出于完整性考虑： 平台：Zynq SoC（FPGA + 2核ARM +外围设备） 内核4.14.0（来自Xilinx）
在这种情况下：我有一个在用户空间中运行的进程，以及一个在内核空间中运行的驱动程序。我已经从用户代码线程中删除了对RT_ *策略的任何使用。
FPGA将数据写入内核内存（ersatz DMA）中的循环缓冲区。
驱动程序的read（）函数从循环缓冲区读取数据并将其复制到用户空间。它通过调用wait_event_interruptible_timeout（）等待数据变为可用。
当完成给定数据量的写入（完成“ DMA”）时，FPGA引发（GPIO）中断时，将调用通过调用devm_request_threaded_irq（）挂接到的中断处理程序。它执行一些琐碎的内务处理，然后调用ake_up_interruptible（）。该驱动程序有五个实例在使用中，它们读取以不同速率生成的数据。这五个中断的DMA完成中断分别在200、200、100、31和10 Hz处发生。系统刻度是100 Hz。
这段代码可以在几分钟到几周内的任何时间运行，然后RCU开始报告停顿，一切都被彻底清理了。 我已经使用kgdb捕获了RCU的投诉，但是RCU在开始注意到停顿后仅20秒钟才开始抱怨。进程列表（来自kdb）始终列出一个正在运行的irq /任何任务，然后是一条错误消息，指出与正在运行的进程表不匹配。一直是不同的irq处理程序，从来没有我的。
在发生这种情况后，FPGA仍在快乐地写入数据并引发中断，从而得出这样的结论：中断已被禁用，或者至少长期禁用。我仍然收到RCU投诉的控制台输出，因此可以运行某些东西。
我不是内核专家，所以很可能我缺少了一些东西。我如何去看看发生了什么？还是我所描述的事物中有明显的错误之处？
帮助！
谢谢
-尼克