Re: [REGRESSION] alg: ahash: Several tests fail during boot on Turris Omnia

Herbert Xu
2024-10-10T06:06:00Z

On Wed, Oct 09, 2024 at 06:48:21PM +0200, Klaus Kudielka wrote:
>
> Oh, I had to increase log_buf_len, to catch everything. Booting is really slow now ;)
> Full dmesg output is attached.

Thanks! This is very helpful.

> [ 4.118765] mv_cesa_ahash_queue_req: 0 (ptrval)
> [ 4.121966] mv_cesa_ahash_queue_req: 0 (ptrval)
> [ 4.126678] mv_cesa_int: 0 0x4ea1 0x80
> [ 4.131394] mv_cesa_ahash_queue_req: 0 (ptrval)
> [ 4.135927] mv_cesa_ahash_complete: 0 (ptrval)
> [ 4.153221] mv_cesa_ahash_req_cleanup: 0 (ptrval)
> [ 4.157942] mv_cesa_int: 0 0x4ea1 0x80
> [ 4.157949] alg: ahash: mv-sha256 test failed (wrong result) on test vector 3, cfg="import/export"
> [ 4.161699] mv_cesa_ahash_complete: 0 (ptrval)
> [ 4.170686] alg: self-tests for sha256 using mv-sha256 failed (rc=-22)
> [ 4.175132] mv_cesa_ahash_complete: 0 (ptrval)
> [ 4.175136] mv_cesa_ahash_req_cleanup: 0 (ptrval)
> [ 4.179589] ------------[ cut here ]------------
> [ 4.184304] mv_cesa_ahash_req_cleanup: 0 (ptrval)

As I suspected, the first multi-request op on a single engine
triggers a failure. This looks like a bug in the TDMA chaining
code.

It is chaining what appears to be a live request. In other words
after we have already passed a chain to the hardware, we appear
to be adding new entries to the end of the chain in
mv_cesa_tdma_chain by assigning last->next_dma.

Unfortunately I don't have documentation for this hardware so I can't
say whether this is definitely illegal but it certainly smells bad :)

Boris, what are the rules of engagement for TDMA chaining?

Is it really OK to add new entries to the chain after it has been
given over to the hardware?

Thanks,