DMA crash ?

[tnt]

Any news on this ?

I also got some runs of just 'degraded' performance rather than 0 (but in fact, it's not runnin more slowly, it just crashed after some iterations IIRC), but I think it's timing dependent and maybe the new driver do something slightly differently causing this.

But in any case, it's not normal ... and I really need this to work. To deal with the limited 32k, I juggle data in/out manually but that's by small blocks and has to be controlled by the core rather than the ARM. not using the dma and using memcpy on the core is just _way_ too slow, I might as well run everything on the host ...

[aolofsson]

Sylvain,
Sorry about the delay in solving this issue. We'll look into it in detail today.
Andreas

[tnt]

So ? Any news ?

[tnt]

I just (finally) managed to update my system to the latest gcc and latest epiphany libs and updated my DMA test code.

Now, it seems more stable. However it also seems a bit less than twice slower than before, this is weird.

[tnt]

[tnt]

[ysapir]

This is an interesting observation, we will certainly need to check that. However, please be aware that the reads and writes travel in different paths, so there is no RAW (Read After Write) guarantee. Please make sure you read that value after some time (say, after the timeout), and not immediately after the e_write().

We are still not 100% sure that the host transactions do not stop at some cache or read/write buffers along the paths. However, I never got a positive indication for such a case, and usually, after some testing and analysis, some other explanation can be found, and the program corrected accordingly.

[tnt]

[ysapir]

Let's try to eliminate one more possible explanation - In our mesh architecture, there is always a precedence of writes to a core over reads from a core, when both done from external space. This means that if core #1 is DMA-ing data into core #0, and you are trying to read data from core #0 (say, host reads mailbox), then the reads are stalled until all writes are completed.

Is it possible that what you try to read is actually being blocked by a continuous DMA-write process?

[tnt]

Well, only core #0 is active here and I'm using its DMA.
From the DMA speeds measurements, I'm _far_ from exceeding the theoritical bandwidth limit in/out of the core.
And then, the reads actually do work and they return a value that's consistent with the previous value that was at that memory location.

Then there is also the fact that the original problem is the core not responding to mailbox commands, but if I repeat the command write, it eventually works.

So all in all, this point to the issue being in the "write" side rather than the "read" side.