UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Observer cgrant
Observer
1,128 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,130 Views
Registered: ‎03-22-2016

Re: Channel Interrupts constantly firing from DMA Subsystem for PCIe

Jump to solution

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

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

Re: Channel Interrupts constantly firing from DMA Subsystem for PCIe

Jump to solution

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

Observer cgrant
Observer
1,078 Views
Registered: ‎04-07-2015

Re: Channel Interrupts constantly firing from DMA Subsystem for PCIe

Jump to solution

@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
Visitor srhodgetts
Visitor
528 Views
Registered: ‎07-31-2018

Re: Channel Interrupts constantly firing from DMA Subsystem for PCIe

Jump to solution

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