cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Observer
Observer
1,674 Views
Registered: ‎04-07-2015

Channel Interrupts constantly firing from DMA Subsystem for PCIe

Jump to solution

I am using the XDMA IP v4.1 with Vivado 2018.1 with 4 channels of streaming C2H DMA channels. When I load the XDMA driver, it seems that the channel engines are constantly servicing channel interrupts, even when I am confident I am not presenting data on the streaming c2h interfaces. Is this by design, or is there a way for me to stop the interrupt generation in the FPGA IP until I present data to the XDMA core? This seems to get the driver in a bad state at times and lock up communication.

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Explorer
Explorer
1,676 Views
Registered: ‎03-22-2016

Two things to check:

 

- Check the user_int_req pin on the XDMA IP block. It should be tied to 0 if you're not using it. There's a bug in some versions of the block automation that tie it to 1 instead, causing it to always trigger user interrupts.

 

- Check what type of interrupts you're using. Try to load the module using MSI or Legacy instead of MSI-X to see if the symptoms change. I haven't gotten confirmation from Xilinx on this, but it appears that you need to select "Enable MSI-X Capability Structure" in order for the default interrupt mode (MSI-X) to work without causing extraneous interrupts.

 

https://forums.xilinx.com/t5/PCI-Express/XDMA-Linux-driver-calling-ISR-repeatedly-during-transfer-without/td-p/879262

 

https://forums.xilinx.com/t5/PCI-Express/Linux-XDMA-module-from-AR65444-rel20180420-ISR-called/td-p/867016

View solution in original post

3 Replies
Highlighted
Explorer
Explorer
1,677 Views
Registered: ‎03-22-2016

Two things to check:

 

- Check the user_int_req pin on the XDMA IP block. It should be tied to 0 if you're not using it. There's a bug in some versions of the block automation that tie it to 1 instead, causing it to always trigger user interrupts.

 

- Check what type of interrupts you're using. Try to load the module using MSI or Legacy instead of MSI-X to see if the symptoms change. I haven't gotten confirmation from Xilinx on this, but it appears that you need to select "Enable MSI-X Capability Structure" in order for the default interrupt mode (MSI-X) to work without causing extraneous interrupts.

 

https://forums.xilinx.com/t5/PCI-Express/XDMA-Linux-driver-calling-ISR-repeatedly-during-transfer-without/td-p/879262

 

https://forums.xilinx.com/t5/PCI-Express/Linux-XDMA-module-from-AR65444-rel20180420-ISR-called/td-p/867016

View solution in original post

Highlighted
Observer
Observer
1,624 Views
Registered: ‎04-07-2015

@jeffsimpson Thanks for leading me to those solutions. The second action solved my problem: I checked "Enable MSI-X Capability Structure" and the extra interrupts went away. 

0 Kudos
Highlighted
Visitor
Visitor
1,074 Views
Registered: ‎07-31-2018

Hi,

With 4 C2H channels streaming, do you ever see the read interrupted by a signal whilst it is waiting for data?  I was wondering if the channels can interrupt each other coming from the same device.

I see this interrupted by a signal issue with 2 channels streaming and MSI-X interrupts enabled.

With enable_credit_mp=1 option, in the transfer_monitor_cyclic function, this wait_event_interruptible_timeout (~Line 3944 in libxdma.c)  can sometimes be interrupted by a signal when no data is available:

rc = wait_event_interruptible_timeout( transfer->wq,
(engine->rx_head!=engine->rx_tail ||
engine->rx_overrun),
msecs_to_jiffies(timeout_ms));

 

0 Kudos