01-18-2018 12:56 AM - edited 01-18-2018 05:57 AM
I'm using the xilinx dma driver to use a device2mem DMA channel. I repeatedly receive the following error:
xilinx-vdma 40400000.dma: Channel cea33c10 has errors 10, cdr 0 tdr 0
The specs state the following about error 10 (reg 4):
DMA Internal Error. This error occurs if the buffer length specified in the fetched descriptor is set to 0. Also, when in Scatter Gather Mode and using the status app length field, this error occurs when the Status AXI4-Stream packet RxLength field does not match the S2MM packet being received by the S_AXIS_S2MM interface. When Scatter Gather is disabled, this error is flagged if any error occurs during Memory write or if the incoming packet is bigger than what is specified in the DMA length register. This error condition causes the AXI DMA to halt gracefully. The DMACR.RS bit is set to 0, and when the engine has completely shut down, the DMASR.Halted bit is set to 1.
This issue is causing the system to miss some DMA transfers. I'm not using scatter gather. Other topics on this forum do not have the same error code. Does somebody have an idea on what might be the cause of this issue?
04-24-2019 04:31 AM
i met the same problem.In normal situation,the dma works perfect.But when tansform the data with another computer with TCP(in muti-thread),it crashed.The err message is :
[ 473.296483] xilinx-vdma a0000000.dma: Channel ffffffc87af41218 has errors 10, cdr 0 tdr 0
so how to deal with this==
03-07-2020 07:13 AM - edited 03-07-2020 07:18 AM
Same problem here. For a first test, I connected M_AXIS_MM2S to S_AXIS_S2MM.
M_AXI_MM2S and M_AXI_S2MM are connected to S_AXI_HP0 on the Zynq (assigned to the address range of the whole DDR RAM 0x00000000..0x07FFFFFF).
No SG configured!
After loading my kernel module, the RX channel (1, S2MM) is started first, but almost immediatly (TX hasn't even started) returns error 10.
The maximum / expected transfer length is 4,096 bytes (0x1000). The destination address 0x0756c000 is well within the physical address range of the RAM.
This is the enhanced Linux log:
# insmod /media/SYSA/mod/csa_dma.ko [ 24.984578] csa_dma 7c00000.csa-dma: dma1chan1 buffer at 0x0756c000 mapped to 0xc756c000 [ 24.993016] csa_dma 7c00000.csa-dma: Started thread using dma1chan1 [ 24.995842] xilinx-vdma 40400000.dma: Channel 7325e40e has errors 10, cdr 0 tdr 0 [ 25.006758] xilinx-vdma 40400000.dma: CR: 0x00017002 [ 25.006758] xilinx-vdma 40400000.dma: SR: 0x00000011 [ 25.006758] xilinx-vdma 40400000.dma: AD: 0x00000000 [ 25.006778] xilinx-vdma 40400000.dma: 0x0756c000
[ 25.019804] xilinx-vdma 40400000.dma: LN: 0x00001000
03-08-2020 07:56 AM
I would like to ask the people who posted issues in this thread.
Is cma enabled for your Linux?
Immediately after booting Linux, if cma is enabled, you will see the following message:
Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.14.0-xlnx-v2018.2-zynqmp-fpga (ichiro@sphinx-vm-ubuntu) (gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.9)) #1 SMP Fri Aug 10 11:05:02 JST 2018 [ 0.000000] Boot CPU: AArch64 Processor [410fd034] [ 0.000000] Machine model: ZynqMP Ultra96 [ 0.000000] efi: Getting EFI parameters from FDT: [ 0.000000] efi: UEFI not found. [ 0.000000] cma: Reserved 256 MiB at 0x0000000070000000
If cma is not enabled, xilinx vdma will fail to allocate contiguous memory space as a buffer.
03-08-2020 07:58 AM
It turned out that all I had to do was uncheck the "Enable Micro DMA" option.
I would have been wise of me to pay close attention to the limitations of that feature as described in PG021:
Enable Micro DMA Checking this option generates a highly optimized DMA which is low on resource count. This setting can be used for applications that transfer a very small amount of data. Program the DMA based on the configuration selected. For example, the maximum bytes that can be transferred per transaction or per BD cannot exceed the following: MMap Data_width * Burst_length/8. Similarly the 4K boundary check is also not implemented in this mode restricting addressing to burst boundaries.
So it seems I have simply exceeded the maximum number of bytes that can be transfered.
03-17-2020 12:40 AM
05-13-2021 07:30 AM - edited 05-13-2021 07:35 AM
I've just had this error too. I don't think this error actually prevented the DMA from running normally or anything. It was just printing a message. But the error did indicate that there was something wrong. So, according to what I've seen in my case, I would say this message should be viewed like "warning, something is suspicious, maybe everything is OK but you might want to take a look".
In my case, what was happening was that I had a hardware IP that was trying to send data to the DMA before Linux had booted up. The DMA was probably accepting a couple of writes from that IP. Then, during the Linux boot, Linux would reset the DMA, which made the DMA lose that bit of data (which was undesirable in my case). After Linux had booted, the first DMA transfer printed this message.
To fix it, I made the hardware IP wait until Linux had booted before actually sending data to the DMA. Now I don't have this message anymore.