Transfer timeout when using XDMA driver on Linux

[planetmarshall]

Expected Behaviour

Data transfer should be successful

Actual Behaviour

Data transfer fails with 512 error and timeout is reported in log

Steps to Reproduce

Build and install the driver from https://github.com/Xilinx/dma_ip_drivers (current master/a7219ec)

Run the following script

def test():
    with open("/dev/xdma0_c2h_0", "rb") as xdma:
        data = xdma.read(4)
        print(data.hex())
 
 
if __name__ == '__main__':
    test()

Log is available here: log.txt

Notes

Works as expected on Windows 10

Linux version 2020.1 (a1d510f4eac17b9f293e0cabcfbf4f3fdb558e50) works as expected but no updated versions work.

System Information

Ubuntu 22.04

Kernel 5.15.0-41-generic

[WarrenWilkinson]

We're seeing the 512 error in a totally different context. I'm trying to see if your test case also fails on our Linux boxes (which are centos ones), but it's not clear from your bug report what you're seeing.

Here I run that program on several machines:

# Identical output on three machines: Mars, Uranus, Bay27, 
-bash-4.2$ modinfo xdma | grep version
version:        2020.2.2
srcversion:     755B8C84314FF43EE2506DC
vermagic:       5.15.1-1.el7.elrepo.x86_64 SMP mod_unload modversions 
-bash-4.2$ uname --kernel-version
#1 SMP Thu Nov 4 19:11:12 EDT 2021
-bash-4.2$ uname --kernel-release
5.15.1-1.el7.elrepo.x86_64
-bash-4.2$ python3 /home/tester/wwilkinson/xdma-test.py 
01f5cbad

Is the return value "01f5cbad" a sign that things have worked, or a sign that we've had the 512 error? In the output of sudo dmesg I don't see any recent logs from the xdma driver. However our version is recent enough that it should be failing if your test case reliably triggers the issue.

[planetmarshall]

...
-bash-4.2$ python3 /home/tester/wwilkinson/xdma-test.py 
01f5cbad

Is the return value "01f5cbad" a sign that things have worked...

Yes. 01f5cbad is the output of the print(data.hex()) call. If it is failing you will see an actual error message from running the Python script.

To get more verbose output, try building the driver in debug mode (see the Makefile for how to do this, I think it varies depending what version you have).