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
