06-21-2018 10:55 AM - edited 06-22-2018 06:41 AM
XDMA module built on Ubuntu 16.04 LTS, Kernel 4.13.0, testing with VCU118, VC709, and an Abaco Kintex Ultrascale board, all with the same results.
Upon inserting the module, the system becomes fairly unresponsive. The mouse lags, and unrelated running processes jump to 100% CPU utilization. Removing the module immediately returns normal functionality. This is without performing any DMA transactions.
Is anyone else seeing this behavior? It does not occur with the previous release of the driver from AR65444.
EDIT: I enabled debugging. I see this occurring continuously:
Jun 22 09:03:49 my-hostname kernel: [ 115.159063] xdma:xdma_isr: (irq=26, dev 0xffff88a28abdd000) <<<< ISR. Jun 22 09:03:49 my-hostname kernel: [ 115.159064] xdma:xdma_isr: ch_irq = 0x00000000 Jun 22 09:03:49 my-hostname kernel: [ 115.159065] xdma:xdma_isr: user_irq = 0x00000001
The ISR is being called continuously, even with no transfer taking place. That explains the high CPU usage of whatever application is in the foreground and the general laggy behavior of the system.
EDIT: I just noticed that the auto-connect for the DMA bridge attached a constant IP block to the usr_irq_req input with the value set to 1. (Vivado 2018.1). That seems to be continuously generating user interrupts. When that constant is changed to a 0, the problem goes away.
06-25-2018 02:53 PM
I have been able to reproduce the issue using our Windows 7 driver as well. I am glad you have come up with a workaround of turning the constant value for usr_irq_req to a 0. I have communicated this behavior to the development team and we are investigating the issue.
02-15-2019 03:50 PM
Can you comment if this has been fixed in recent issues of Vivado?
There seem to be a few bugs with the XDMA PCIe sames and I'm trying to figure out if this is a potential cause.
05-27-2020 02:15 PM
We are still seeing this issue with Vivado 2019.2 using the AC701 evaluation board. Has any development been done to fix this? We are still seeing the spurious interrupts even with 0 tied to usr_irq_req. We have legacy interrupts set to NONE, MSI enabled, and MSI-X disabled. We tried enabling MSI-X, but after doing that we cant get any interrupts to occur (not even expected ones).