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

[Herbert Xu]

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,
-- 
Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt