In the old 4.1.35-based kernel tree that was included with the "old" SDK, the CAAM driver worked well and I was able to do full-disk encryption via DM Crypt / LUKS / cryptsetup. With both the 4.9 and 4.14 kernel trees from LSDK18.03 the driver hangs while doing IO to a dm crypt target.
Has anyone else run into this problem?
sysrq-t shows that the workqueues that are in charge of doing the encryption/decryption are waiting for completion:
[ 595.478281] kworker/u2:0 D 0 6 2 0x00000000
[ 595.478293] Workqueue: kcryptd kcryptd_crypt
[ 595.478296] Call trace:
[ 595.478302] [<ffff000008085ea4>] __switch_to+0xa4/0xc0
[ 595.478308] [<ffff000008c23e88>] __schedule+0x188/0x590
[ 595.478314] [<ffff000008c242c8>] schedule+0x38/0xa0
[ 595.478321] [<ffff000008c2726c>] schedule_timeout+0x17c/0x240
[ 595.478328] [<ffff000008c24ecc>] wait_for_common+0x9c/0x140
[ 595.478334] [<ffff000008c24f84>] wait_for_completion+0x14/0x20
[ 595.478339] [<ffff000008987a9c>] crypt_convert+0x2bc/0x490
[ 595.478344] [<ffff000008987ea4>] kcryptd_crypt+0x234/0x3a0
[ 595.478350] [<ffff0000080d74d8>] process_one_work+0x1d8/0x370
[ 595.478356] [<ffff0000080d76b8>] worker_thread+0x48/0x4c0
[ 595.478361] [<ffff0000080ddcb8>] kthread+0xe8/0xf0
[ 595.478366] [<ffff0000080836c0>] ret_from_fork+0x10/0x50
Leaving the "hang" overnight leaves additional messages on the console (with caam debugging enabled):
[ 1805.852680] caam_jr 1710000.jr: caam_read: start reading at buffer 0, idx 2576
[ 1805.852692] caam_jr 1710000.jr: caam_read: start reading at buffer 0, idx 2640
[ 1805.852700] caam_jr 1710000.jr: caam_read: start reading at buffer 0, idx 2704
[ 1805.852707] caam_jr 1710000.jr: caam_read: start reading at buffer 0, idx 2768
There were approx 39 of these messages every 85-95 minutes. I'm not sure if this indicates that some forward progress is being made. The "idx" continued to increment at each printing.