Re: XFRM Stats
oops yes, completely forgot the lifetime stats. Thanks Herbert. I will check this out, but after a rekey, are the stats still preserved? thanks --Raj On Wed, Jun 21, 2017 at 7:42 PM, Herbert Xu wrote: > Raj Ammanur wrote: >> Hi Crypto/Xfrm Team, >> >> I was wondering if there has been any discussion in the past >> about adding stats in Xfrm to count the packets going in/out of >> this sub-system? Right now we only have error stats. > > Have you looked at ip -s x s? > > Cheers, > -- > Email: Herbert Xu > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
XFRM Stats
Hi Crypto/Xfrm Team, I was wondering if there has been any discussion in the past about adding stats in Xfrm to count the packets going in/out of this sub-system? Right now we only have error stats. thanks --Raj
Re: Alg errors with Intel QAT Card
those previous alg error msgs are gone with 4.11.3-202.fc25.x86_64, but now I see multiple tracebacks like the ones below. Looks like its been reported a few months back with 4.10.0-rc3+ , but with no response or further update: https://www.spinics.net/lists/linux-crypto/msg23699.html [ 182.697358] WARNING: CPU: 6 PID: 558 at crypto/algapi.c:348 crypto_wait_for_test+0x60/0x80 [ 182.699505] Modules linked in: ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge st p llc ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_raw ip6table_mangle ip6table_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack libcrc32c iptable_raw iptable_mangle iptable_security ebtable_filter ebtables ip6table_filter ip6_tables crct10dif_pclmul ppdev qat_dh895xcc(+) crc32_pclmul intel_qat ghash_clmulni_intel joydev parport_pc parport acpi_cpufreq tpm_tis t pm_tis_core tpm virtio_balloon qemu_fw_cfg i2c_piix4 dh_generic authenc nfsd auth_rpcgss nfs_acl lockd grace sunrpc virtio_net virtio_blk cir rus drm_kms_helper ttm crc32c_intel drm serio_raw virtio_pci ixgbevf virtio_ring virtio ata_generic pata_acpi [ 182.705805] CPU: 6 PID: 558 Comm: systemd-udevd Not tainted 4.11.3-202.fc25.x86_64 #1 [ 182.706502] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 04/01/2014 [ 182.707269] Call Trace: [ 182.707513] dump_stack+0x63/0x86 [ 182.707825] __warn+0xcb/0xf0 [ 182.708098] warn_slowpath_null+0x1d/0x20 [ 182.708463] crypto_wait_for_test+0x60/0x80 [ 182.708842] crypto_register_alg+0x5b/0x70 [ 182.709208] crypto_register_algs+0x3a/0x80 [ 182.709599] qat_algs_register+0x6c/0xc0 [intel_qat] [ 182.710041] adf_dev_start+0xd1/0x160 [intel_qat] [ 182.710477] adf_probe+0x5ec/0x610 [qat_dh895xcc] [ 182.710909] local_pci_probe+0x45/0xa0 [ 182.711250] pci_device_probe+0xfa/0x150 [ 182.711623] driver_probe_device+0x2bb/0x460 [ 182.712009] __driver_attach+0xdf/0xf0 [ 182.712349] ? driver_probe_device+0x460/0x460 [ 182.712751] bus_for_each_dev+0x6c/0xc0 [ 182.713099] driver_attach+0x1e/0x20 [ 182.713426] bus_add_driver+0x170/0x270 [ 182.713773] driver_register+0x60/0xe0 [ 182.714113] ? 0xc01ba000 [ 182.714425] __pci_register_driver+0x4c/0x50 [ 182.714811] adfdrv_init+0x2f/0x1000 [qat_dh895xcc] [ 182.715255] do_one_initcall+0x52/0x1a0 [ 182.715618] ? kmem_cache_alloc_trace+0x159/0x1b0 [ 182.716047] ? do_init_module+0x27/0x1f8 [ 182.716406] do_init_module+0x5f/0x1f8 [ 182.716754] load_module+0x27cc/0x2be0 [ 182.717096] SYSC_init_module+0x173/0x190 [ 182.717461] ? SYSC_init_module+0x173/0x190 [ 182.717837] SyS_init_module+0xe/0x10 [ 182.718169] do_syscall_64+0x67/0x180 [ 182.719638] entry_SYSCALL64_slow_path+0x25/0x25 [ 182.721178] RIP: 0033:0x7fd22ee715ca [ 182.722622] RSP: 002b:7ffc498bc428 EFLAGS: 0246 ORIG_RAX: 00af [ 182.724415] RAX: ffda RBX: 55ba9680ca30 RCX: 7fd22ee715ca [ 182.726161] RDX: 7fd22f9a3995 RSI: 3f03 RDI: 55ba97066a00 [ 182.727897] RBP: 7fd22f9a3995 R08: 55ba9680d460 R09: [ 182.729624] R10: R11: 0246 R12: 55ba97066a00 [ 182.731326] R13: 55ba9681b030 R14: 0002 R15: 55ba9680ca30 On Tue, Jun 13, 2017 at 1:32 PM, Raj Ammanur wrote: > Hi Neil & Salvatore, > > thanks for the replies. The soft reboot hasn't helped. I am trying a previous > kernel version that works with a similar card that we installed in > another server > and that works fine. Will keep you posted. > > Neil: have you found fix/workaround for the firmware errors or you just using > a soft reboot? by that, you just mean unload and load the kernel modules or > a system reboot. I have tried both. > > thanks > --Raj > > On Tue, Jun 13, 2017 at 5:30 AM, Neil Horman wrote: >> On Mon, Jun 12, 2017 at 03:52:07PM +, Benedetto, Salvatore wrote: >>> Hi Raj, >>> >>> I've compiled and tested kernel 4.12.0-rc4 and I can't reproduce your issue. >>> Are you seeing any of this with a previous kernel version? If not, git >>> bisect might >>> help us finding the root-cause. >>> Have you tried with another platform/hw? >>> >>> Regards, >>> Salvatore >>> >> Try a soft reboot and see if the error clears up. This looks a bit >> reminscient >> of some firmware errors we've been chasing down >> Neil >> >>> > -Original Message- >>> > From: linux-crypto-ow...@vger.kernel.org [mailto:linux-crypto- >>> > ow...@vger.kernel.org] On Behalf Of Raj Ammanur >>> > Sent: Friday, June 9, 2017 7:37 PM >>> > To: Linux Crypto Mailing List >>> > Subject: Alg errors with Intel QAT Card
Re: Alg errors with Intel QAT Card
Hi Neil & Salvatore, thanks for the replies. The soft reboot hasn't helped. I am trying a previous kernel version that works with a similar card that we installed in another server and that works fine. Will keep you posted. Neil: have you found fix/workaround for the firmware errors or you just using a soft reboot? by that, you just mean unload and load the kernel modules or a system reboot. I have tried both. thanks --Raj On Tue, Jun 13, 2017 at 5:30 AM, Neil Horman wrote: > On Mon, Jun 12, 2017 at 03:52:07PM +, Benedetto, Salvatore wrote: >> Hi Raj, >> >> I've compiled and tested kernel 4.12.0-rc4 and I can't reproduce your issue. >> Are you seeing any of this with a previous kernel version? If not, git >> bisect might >> help us finding the root-cause. >> Have you tried with another platform/hw? >> >> Regards, >> Salvatore >> > Try a soft reboot and see if the error clears up. This looks a bit > reminscient > of some firmware errors we've been chasing down > Neil > >> > -Original Message----- >> > From: linux-crypto-ow...@vger.kernel.org [mailto:linux-crypto- >> > ow...@vger.kernel.org] On Behalf Of Raj Ammanur >> > Sent: Friday, June 9, 2017 7:37 PM >> > To: Linux Crypto Mailing List >> > Subject: Alg errors with Intel QAT Card >> > >> > Hi >> > >> > I am seeing the below errors after installing an Intel QAT card >> > and loading the upstreamed qat_dh895xcc and intel_qat modules. >> > >> > Have others seen similar errors and know if this is a known issue >> > and a fix exists or know whats going on ? This is with 4.12.0-rc4+ >> > version of the kernel. >> > >> > Any help is sincerely appreciated. >> > >> > thanks >> > --Raj >> > >> > >> > [3.639046] dh895xcc :00:0b.0: qat_dev0 started 12 acceleration >> > engines >> > [4.168887] alg: skcipher-ddst: Test 5 failed (invalid result) on >> > encryption for qat_aes_cbc >> > [4.217866] alg: skcipher-ddst: Chunk test 1 failed on encryption >> > at page 0 for qat_aes_ctr >> > [4.282042] alg: skcipher: Test 4 failed (invalid result) on >> > encryption for qat_aes_xts >> > [4.395210] alg: akcipher: test 1 failed for qat-rsa, err=-22 >> > [root@dhcp-swlab-681 ~]# dmesg | grep -i alg >> > [1.499336] alg: No test for pkcs1pad(rsa,sha256) >> > (pkcs1pad(rsa-generic,sha256)) >> > [2.562511] SELinux: Class alg_socket not defined in policy. >> > [4.168887] alg: skcipher-ddst: Test 5 failed (invalid result) on >> > encryption for qat_aes_cbc >> > [4.217866] alg: skcipher-ddst: Chunk test 1 failed on encryption >> > at page 0 for qat_aes_ctr >> > [4.282042] alg: skcipher: Test 4 failed (invalid result) on >> > encryption for qat_aes_xts >> > [4.367682] alg: akcipher: encrypt test failed. Invalid output >> > [4.395210] alg: akcipher: test 1 failed for qat-rsa, err=-22 >> > [4.431827] alg: dh: generate public key test failed. Invalid output >> > [4.431829] alg: dh: test failed on vector 1, err=-22 >> > >> > >> > 83:00.0 Co-processor: Intel Corporation DH895XCC Series QAT >> > Subsystem: Intel Corporation Device >> > Physical Slot: 2 >> > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- >> > Stepping- SERR+ FastB2B- DisINTx+ >> > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- >> > SERR- > > Latency: 0, Cache Line Size: 32 bytes >> > Interrupt: pin A routed to IRQ 35 >> > NUMA node: 1 >> > Region 0: Memory at fb90 (64-bit, prefetchable) [size=512K] >> > Region 2: Memory at fbd4 (64-bit, non-prefetchable) [size=256K] >> > Region 4: Memory at fbd0 (64-bit, non-prefetchable) [size=256K] >> > Capabilities: [b0] MSI: Enable- Count=1/1 Maskable+ 64bit+ >> > Address: Data: >> > Masking: Pending: >> > Capabilities: [60] MSI-X: Enable+ Count=33 Masked- >> > Vector table: BAR=2 offset=0003b000 >> > PBA: BAR=2 offset=0003b800 >> > Capabilities: [6c] Power Management version 3 >> > Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot- >> > ,D3cold-) >> > Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- >> > Capabilities: [74] Express (v2) Endpoint, MSI 00 >> > DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <128ns, L1 <1us >>
Alg errors with Intel QAT Card
Hi I am seeing the below errors after installing an Intel QAT card and loading the upstreamed qat_dh895xcc and intel_qat modules. Have others seen similar errors and know if this is a known issue and a fix exists or know whats going on ? This is with 4.12.0-rc4+ version of the kernel. Any help is sincerely appreciated. thanks --Raj [3.639046] dh895xcc :00:0b.0: qat_dev0 started 12 acceleration engines [4.168887] alg: skcipher-ddst: Test 5 failed (invalid result) on encryption for qat_aes_cbc [4.217866] alg: skcipher-ddst: Chunk test 1 failed on encryption at page 0 for qat_aes_ctr [4.282042] alg: skcipher: Test 4 failed (invalid result) on encryption for qat_aes_xts [4.395210] alg: akcipher: test 1 failed for qat-rsa, err=-22 [root@dhcp-swlab-681 ~]# dmesg | grep -i alg [1.499336] alg: No test for pkcs1pad(rsa,sha256) (pkcs1pad(rsa-generic,sha256)) [2.562511] SELinux: Class alg_socket not defined in policy. [4.168887] alg: skcipher-ddst: Test 5 failed (invalid result) on encryption for qat_aes_cbc [4.217866] alg: skcipher-ddst: Chunk test 1 failed on encryption at page 0 for qat_aes_ctr [4.282042] alg: skcipher: Test 4 failed (invalid result) on encryption for qat_aes_xts [4.367682] alg: akcipher: encrypt test failed. Invalid output [4.395210] alg: akcipher: test 1 failed for qat-rsa, err=-22 [4.431827] alg: dh: generate public key test failed. Invalid output [4.431829] alg: dh: test failed on vector 1, err=-22 83:00.0 Co-processor: Intel Corporation DH895XCC Series QAT Subsystem: Intel Corporation Device Physical Slot: 2 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR-
Re: [PATCH] crypto: aesni-intel - avoid IPsec re-ordering
On Wed, Jan 20, 2016 at 12:38 AM, Herbert Xu wrote: > On Wed, Jan 20, 2016 at 12:31:46AM -0800, Raj Ammanur wrote: >> >> RAJ: ok. would it also be useful to be able to set the length as a module >> load time parameter? > > That would be a bad interface. If we wanted to have an adjustable > limit it needs to be set by the entity that is creating the tfm, > i.e., IPsec. > RAJ: Agreed, but it also has been useful for me for testing/debugging to be able to specify the size to a KLM, since the other stuff is built into the kernel. We atleast got rid of the dup acks, although the out of order pkts still remain. >> RAJ: hmm, thats true, yes. >> >> so, is the below description, that you wrote in one of your email replies, >> the solution for which you are going to create a patch? >> >> > So what I'm thinking of is to have the softirq path forcibly regain >> > control from cryptd where possible. This is tricky because cryptd >> > might be in the middle of processing a request. So that's why I'd >> > like to disable softirqs while we're processing a request. > > Yes. > RAJ: Will wait for the patch to take a look and try it out and test it. Sincerely appreciate it. thanks --Raj > Cheers, > -- > Email: Herbert Xu > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt > -- > To unsubscribe from this list: send the line "unsubscribe linux-crypto" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
