cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
mark.harfouche
Observer
Observer
744 Views
Registered: ‎11-05-2014

AR65444 in streaming mode reports that it read more bytes than requested.

I setup the traffic generator to generate 512 bytes of traffic on a streaming interface.

 

Then I request 256 bytes using the driver provided in AR65444 on the c2h streaming interface.

 

The driver decides to write 512 bytes wroth of data. Fun fun!!!

```

$ ./dma_from_device --size 256 -c 1                                                                                                                   
/dev/xdma0_c2h_0, R off 0x0, 0x200 != 0x100.
read file: Input/output error

```

If you try to run the dma_from_device as provided, it will "return success" but you should look at the inequality, showing that the number of `read` bytes (on the left hand side) is different than the requested number of bytes (on the right hand side).

 

I'm working on fixing this and other issues

https://github.com/ramonaoptics/xilinx-dma-driver/

provided I have enough time to do so.

 

To my knowledge, this issue was first reported in

https://forums.xilinx.com/t5/PCI-Express/C2H-Streaming-XDMA-Linux-Driver-Broken/td-p/833977

by @dwd_pete

 

but that conversation seems to have changed directions.

 

@dwd_pete, I'm not sure if you can point me in the right direction to implement this specific fix. but if yo ucould it would be greatly appreciated!

 

Upon further inspection, it appears as the streaming mode driver reports the total number of bytes consumed by the driver. It doesn't seem to actually write them to your buffer.

 

I can confirm this because I can see that the last 256 bytes are still empty in my application.

 

I guess the return value is correct in the sense that it consumed the bytes, but incorrect in the sense that only 256 bytes were written to my buffer.

 

`man 2 read` doesn't specify what should happen in the case that more bytes were consumed from an interface.

 

I personally think that the driver should keep them in a temporary buffer, but who am I to say.

0 Kudos
1 Reply
501 Views
Registered: ‎08-13-2019

I am also seeing this (on a ZCU106 board hooked to a x86_64 SBC). But unlike what you're reporting, I *am* seeing data corruption past the read request's length. In fact, that's how I found this problem-- some run-time check glibc was doing alerted me to the buffer overflow. My (dumb) workaround for now is to make the buffer bigger and to process the number of bytes that were returned. Since the data has a pattern to it, I know the extra data received is actually correct data.

 

0 Kudos