10-24-2018 01:40 AM
We are using the example IP for XDMA using AXI stream (h2c and c2h channels loopback) and we encounter an issue when using XDMA drivers, dma_streaming_test.sh example :
~/Xilinx_Answer_65444_Linux_Files_rel20180420/tests# ./dma_streaming_test.sh 100 100 1 Info: Running PCIe DMA streaming test transfer size: 100 transfer count: 100 Info: Only channels that have both h2c and c2h will be tested as the other interfaces are left unconnected in the PCIe DMA example design. Info: DMA setup to read from c2h channel 0. Waiting on write data to channel 0. Info: Writing to h2c channel 0. This will also start reading data[ 359.196882] BUG: scheduling while atomic: dma_to_device/3510/0x00000002 on c2h channel 0. Info: Wait th[ 359.205973] Modules linked in:e for current transactions to com 8021qplete. garp stp mrp xdma(O) goodix galcore(O) ipv6 [ 359.219940] Preemption disabled at:[ 359.223426] [<ffff000000cee3a0>] xdma_xfer_submit+0x1a0/0x9d8 [xdma]
That subject seems to be related to this issue
Someone found that issue when using XDMA drivers? It seems scheduler prempted the task or handle a ressource already used.
11-08-2018 08:59 AM
Could you please confirm the OS and architecture (x86, Embedded) you are using?
11-12-2018 06:27 AM
As Beth requested, do let us know the OS and the architecture. Another point is, you seem to be testing with tranfersize of 100. Could you try with 1K, 4K, 8K, 258K or 32M? You will need to make few changes as described in the link below:
Let us know how that goes.
11-12-2018 06:40 AM
A silly side question, if allowed:
As I see the OP uses the content of the ..._rel20180420 folder, as opposed to the Answer 65444 folder without that number at the end.
What's basically the differnce between the drivers in those two folders?
11-12-2018 07:00 AM
The one with the number is the enhanced version. The one without the number is legacy driver with less functionality. The recommendation is to use the latest version with the number.
11-29-2018 09:14 AM - edited 11-29-2018 09:23 AM
Sorry the late answer : thank you for answering.
We are using ARM (embedded linux 4.9.88 kernel on NXP iMX) CPU and saw the note about x86 support, but we got to make it work anyway.
On that post, someone said that you will add more support platforms : do you know when you will release ARM one?
If you cannot say when it will be available, are you able to say us the main issue/problems/parts of code to be reviewed to make it work on ARM architecture please?