Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1237089
Summary: | Power8(ppc64(le)) machine fails to boot 4.1.0+ kernel | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jakub Čajka <jcajka> | ||||||
Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | unspecified | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | 23 | CC: | bugproxy, dan, gansalmon, gustavold, itamar, jjborcean, jonathan, kernel-maint, madhu.chinakonda, mchehab, pbrobinson | ||||||
Target Milestone: | --- | Keywords: | Reopened | ||||||
Target Release: | --- | ||||||||
Hardware: | ppc64le | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | 4.1.6-201.fc22 | Doc Type: | Bug Fix | ||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2015-11-04 11:24:06 UTC | Type: | Bug | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Bug Depends On: | |||||||||
Bug Blocks: | 1071880, 1051573 | ||||||||
Attachments: |
|
Description
Jakub Čajka
2015-06-30 10:46:08 UTC
Seems to fails similarly on ppc64(same machine, kernel 4.1.0-0.rc7.git0.1.fc23.ppc64). . . . [ 0.761763] hub 2-0:1.0: 4 ports detected [ 0.761923] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 0.761990] ehci-pci: EHCI PCI platform driver [ 0.762047] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 0.762112] ohci-pci: OHCI PCI platform driver [ 0.762167] uhci_hcd: USB Universal Host Controller Interface driver [ 0.762260] usbcore: registered new interface driver usbserial [ 0.762321] usbcore: registered new interface driver usbserial_generic [ 0.762381] usbserial: USB Serial support registered for generic [ 0.762526] mousedev: PS/2 mouse device common for all mice [ 0.762926] device-mapper: uevent: version 1.0.3 [ 0.763188] device-mapper: ioctl: 4.31.0-ioctl (2015-3-12) initialised: dm-devel [ 0.764836] Using 'aes-generic' as fallback implementation. [ 0.764933] crypto_register_alg 'aes' = 0 [ 0.766239] Using 'aes-generic' as fallback implementation. [ 0.766286] Using 'cbc(p8_aes)' as fallback implementation. [ 0.766399] Unrecoverable VSX Unavailable Exception f40 at c000000000795f20 [ 0.766457] Oops: Unrecoverable VSX Unavailable Exception, sig: 6 [#1] [ 0.766514] SMP NR_CPUS=1024 NUMA PowerNV [ 0.766561] Modules linked in: [ 0.766609] CPU: 11 PID: 603 Comm: cryptomgr_test Not tainted 4.1.0-0.rc7.git0.1.fc23.ppc64 #1 [ 0.766688] task: c000001e48706270 ti: c000001e48794000 task.ti: c000001e48794000 [ 0.766755] NIP: c000000000795f20 LR: c00000000079754c CTR: 0000000000000000 [ 0.766823] REGS: c000001e48797060 TRAP: 0f40 Not tainted (4.1.0-0.rc7.git0.1.fc23.ppc64) [ 0.766901] MSR: 9000000102009032 <SF,HV,VEC,EE,ME,IR,DR,RI> CR: 44022224 XER: 00000000 [ 0.767073] CFAR: c000000000795ec8 SOFTE: 1 GPR00: ffffffffffffffff c000001e487972e0 c0000000015be200 c000000fec5f0000 GPR04: c000000fec5f0000 0000000000000170 c000000fec0f01d4 c000001e48797998 GPR08: 0000000000000010 0000000000000003 000000000000016f c000001e4879732f GPR12: 0000000000000000 c00000000fda6880 c0000000014957e8 c000000000c2d9a8 GPR16: c000001e48797970 0000000000000100 c000001e48797998 0000000000000000 GPR20: 0000000000000005 c000001e487977f0 c0000000014956e8 0000000000000000 GPR24: 0000000000010000 0000000000000000 0000000000000020 0000000000000030 GPR28: 0000000000000040 0000000000000050 0000000000000060 0000000000000070 [ 0.767944] NIP [c000000000795f20] _aesp8_cbc_decrypt8x+0x140/0x768 [ 0.768002] LR [c00000000079754c] .p8_aes_cbc_decrypt+0xbc/0x180 [ 0.768058] Call Trace: [ 0.768082] [c000001e487972e0] [c000001e48797370] 0xc000001e48797370 (unreliable) [ 0.768162] [c000001e487974a0] [c00000000079751c] .p8_aes_cbc_decrypt+0x8c/0x180 [ 0.768243] [c000001e487975e0] [c00000000044de50] .async_decrypt+0x60/0x80 [ 0.768312] [c000001e48797680] [c000000000456708] .__test_skcipher+0x458/0xb50 [ 0.768391] [c000001e48797a80] [c000000000458510] .test_skcipher+0x50/0x120 [ 0.768459] [c000001e48797b10] [c0000000004586b0] .alg_test_skcipher+0xd0/0x120 [ 0.768539] [c000001e48797ba0] [c0000000004582cc] .alg_test+0x16c/0x360 [ 0.768607] [c000001e48797cb0] [c000000000454a04] .cryptomgr_test+0x64/0x80 [ 0.768676] [c000001e48797d30] [c0000000000e875c] .kthread+0x10c/0x130 [ 0.768745] [c000001e48797e30] [c000000000009668] .ret_from_kernel_thread+0x58/0x70 [ 0.768823] Instruction dump: [ 0.768858] 7fbc30ce 137be2ab 7fdd30ce 139ceaab 7ffe30ce 13bdf2ab 7ddf30ce 13defaab [ 0.768972] 7f0058ce 13ff72ab 7f2858ce 3863fff1 <7c001e99> 7c281e99 7c5a1e99 7c7b1e99 [ 0.769091] ---[ end trace ce8622f8f5692718 ]--- [ 0.773334] [ 0.773359] note: cryptomgr_test[603] exited with preempt_count 2 Seems the same with locally built kernel version 4.2.0-0.rc0.git4.1.fc23.ppc64le . . . [ 0.958193] device-mapper: uevent: version 1.0.3 [ 0.958657] device-mapper: ioctl: 4.32.0-ioctl (2015-6-26) initialised: dm-devel [ 0.966696] Using 'aes-generic' as fallback implementation. [ 0.966840] crypto_register_alg 'aes' = 0 [ 0.968882] Using 'aes-generic' as fallback implementation. [ 0.968931] Using 'cbc(p8_aes)' as fallback implementation. [ 0.969136] Unrecoverable VSX Unavailable Exception f40 at c0000000008623c4 [ 0.969195] Oops: Unrecoverable VSX Unavailable Exception, sig: 6 [#1] [ 0.969253] SMP NR_CPUS=1024 NUMA PowerNV [ 0.969301] Modules linked in: [ 0.969349] CPU: 8 PID: 646 Comm: cryptomgr_test Not tainted 4.2.0-0.rc0.git4.1.fc23.ppc64le #1 [ 0.969429] task: c000000fe2973e60 ti: c000000fe29e8000 task.ti: c000000fe29e8000 [ 0.969499] NIP: c0000000008623c4 LR: c000000000863d1c CTR: 0000000000000000 [ 0.969568] REGS: c000000fe29eb0e0 TRAP: 0f40 Not tainted (4.2.0-0.rc0.git4.1.fc23.ppc64le) [ 0.969647] MSR: 9000000102009033 <SF,HV,VEC,EE,ME,IR,DR,RI,LE> CR: 44022824 XER: 00000000 [ 0.969832] CFAR: c000000000862368 SOFTE: 1 GPR00: ffffffffffffffff c000000fe29eb360 c000000001622900 c000000fe2d80000 GPR04: c000000fe2d80000 0000000000000170 c000000fe2ce01cc c000000fe29eba28 GPR08: 0000000000000010 0000000000000003 0000000000000008 c000000fe29eb3af GPR12: 0000000000000000 c00000000fda4c00 c00000000155f180 c000000fe2040180 GPR16: c000000fe29eb940 0000000000000100 c000000fe29eba28 0000000000000000 GPR20: 0000000000000005 c000000fe29eb800 c00000000155f080 0000000000000000 GPR24: 0000000000010000 0000000000000000 0000000000000020 0000000000000030 GPR28: 0000000000000040 0000000000000050 0000000000000060 0000000000000070 [ 0.971092] NIP [c0000000008623c4] _aesp8_cbc_decrypt8x+0x144/0x850 [ 0.971205] LR [c000000000863d1c] p8_aes_cbc_decrypt+0xdc/0x1c0 [ 0.971319] Call Trace: [ 0.971364] [c000000fe29eb360] [c000000fe29eb3b0] 0xc000000fe29eb3b0 (unreliable) [ 0.971523] [c000000fe29eb520] [c000000000863ce4] p8_aes_cbc_decrypt+0xa4/0x1c0 [ 0.971682] [c000000fe29eb610] [c0000000004f9560] async_decrypt+0x60/0x80 [ 0.971818] [c000000fe29eb660] [c0000000005031a4] __test_skcipher+0x474/0xc50 [ 0.971954] [c000000fe29ebb10] [c000000000505808] test_skcipher+0x58/0x120 [ 0.972091] [c000000fe29ebb50] [c0000000005059b0] alg_test_skcipher+0xe0/0x130 [ 0.972246] [c000000fe29ebbd0] [c0000000005055b8] alg_test+0x168/0x360 [ 0.972382] [c000000fe29ebcd0] [c0000000005017bc] cryptomgr_test+0x6c/0x90 [ 0.972516] [c000000fe29ebd00] [c0000000000f3440] kthread+0x120/0x140 [ 0.972653] [c000000fe29ebe30] [c0000000000095b4] ret_from_kernel_thread+0x5c/0xa8 [ 0.972810] Instruction dump: [ 0.972876] 137cdaab 7fdd30ce 139de2ab 7ffe30ce 13beeaab 7ddf30ce 13dff2ab 7f0058ce [ 0.973096] 13eefaab 7f2858ce 3863fff1 39400008 <7c001e99> 7cc0500c 106f030c 7c281e99 [ 0.973320] ---[ end trace 1abb238ddc52353e ]--- [ 0.974318] [ 0.974365] note: cryptomgr_test[646] exited with preempt_count 2 [ 0.974495] cryptomgr_test (646) used greatest stack depth: 9200 bytes left ------- Comment From leosilva.com 2015-07-09 16:47 EDT------- It's seems related with kernel only. VMX driver uses altivec instructions as VMX registers. We are not using any VSX registers. And that is why we have a ' enable_kernel_altivec' in our code. Since VSX enable code is as a comment in kernel, I'd ask if anyone from kernel has any info or update about this issue? From VMX driver side we were able to reproduce this on a p8/fedora21 le. If it's supposed to enable_vsx fix this, we also haven't any vsx there,as I said before. However form security team side we will keep debugs in Be and see what we can figure out about. Thanks for your support ------- Comment From aravam.com 2015-07-09 20:33 EDT------- (In reply to comment #8) > It's seems related with kernel only. I'm not sure what this sentence means? > VMX driver uses altivec instructions as VMX registers. We are not using any > VSX registers. And that is why we have a ' enable_kernel_altivec' in our > code. > > Since VSX enable code is as a comment in kernel, I'd ask if anyone from > kernel has any info or update about this issue? There is no kernel use of VSX currently, so there is no need for enable_vsx() to be called anywhere. It seems like this new crypto code changed that. > From VMX driver side we were able to reproduce this on a p8/fedora21 le. If > it's supposed to enable_vsx fix this, we also haven't any vsx there,as I > said before. > > However form security team side we will keep debugs in Be and see what we > can figure out about. Looking at drivers/crypto/vmx/aesp8-ppc.pl : "Data alignment in parallelizable modes is # handled with VSX loads and stores, which implies MSR.VSX flag being # set." RH, would it be possible to trap to xmon (or Leonidas, since you have the reproduction on p8/fc21) and get the disassembly for what instruction is actually causing the VSX unavailable exception? ------- Comment From leosilva.com 2015-07-09 20:43 EDT------- (In reply to comment #9) > (In reply to comment #8) > > It's seems related with kernel only. > > I'm not sure what this sentence means? > Sorry, fingers faster than thinking...so it's not an issue on kernel side. > > Looking at drivers/crypto/vmx/aesp8-ppc.pl : "Data alignment in > parallelizable modes is > # handled with VSX loads and stores, which implies MSR.VSX flag being > # set." yes, I see the point now. Thank you for clarify me. > > RH, would it be possible to trap to xmon (or Leonidas, since you have the > reproduction on p8/fc21) and get the disassembly for what instruction is > actually causing the VSX unavailable exception? Good point. thank you for your support ------- Comment From leosilva.com 2015-07-09 21:44 EDT------- As it was already known vmx-crypto.ko is not using only VMX instructions, but it's also using VSX instruction for unaligned memory reference (as NISHANTH says in comment #9). Instructions such as lxsdx which needs VSX enable to run. For references, you can find this calls in drivers/crypto/vmx/aesp8-ppc.pl. Instructions with _u after VMX name are translated to another on ppc-xlate.pl file. In this particularly case lxdx_u is transform in lxsdx a VSX instruction. I could not debug it yet, but I'm pretty sure this part of the code is raise oops/VSX exception. PS Line in ppc-xlate.pl my $lvdx_u = sub { vsxmem_op(@_, 588); }; # lxsdx From Power ISA: VSX lxsdx Load VSR Scalar Doubleword Indexed PS2: Say that and for reasons of performance we need a way to enable VSX. ------- Comment From aravam.com 2015-07-09 22:27 EDT------- (In reply to comment #11) > As it was already known vmx-crypto.ko is not using only VMX instructions, > but it's also using VSX instruction for unaligned memory reference (as > NISHANTH says in comment #9). Instructions such as lxsdx which needs VSX > enable to run. > > For references, you can find this calls in drivers/crypto/vmx/aesp8-ppc.pl. > Instructions with _u after VMX name are translated to another on > ppc-xlate.pl file. In this particularly case lxdx_u is transform in lxsdx a > VSX instruction. > > I could not debug it yet, but I'm pretty sure this part of the code is raise > oops/VSX exception. > > > PS > Line in ppc-xlate.pl > my $lvdx_u = sub { vsxmem_op(@_, 588); }; # lxsdx > > From Power ISA: > VSX lxsdx Load VSR Scalar Doubleword Indexed > > PS2: Say that and for reasons of performance we need a way to enable VSX. Hrm, so a couple of questions immediately come to mind. I think the reason that enable_kernel_vsx() is commented out is that there are no users. It seems like it should work as-is, just put it back in and call it in the right path. *But* I also see this in the root powerpc Makefile: arch/powerpc/Makefile:KBUILD_CFLAGS += So does those files that use VSX as above get built somehow differently? Or ... am I misunderstanding something? ------- Comment From leosilva.com 2015-07-10 17:19 EDT------- Patches attached fixes Kernel exception issue. I applied and test it. Also verified an issue related with self test, but not related with the prior VSX crash. Thanks for you support. Created attachment 1050762 [details]
Enable VSX code
Created attachment 1050763 [details]
Call enable_kernel_vsx() in order to make vsx instruction available for vmx
IBM, I suppose those patches are on the way to the mainline kernel. Do you have mailing list links or powerpc git tree ids so they could be integrated in Fedora kernel before they hit mainline? Thanks, Dan. ------- Comment From leosilva.com 2015-07-13 16:53 EDT------- (In reply to comment #16) > IBM, I suppose those patches are on the way to the mainline kernel. Do you > have mailing list links or powerpc git tree ids so they could be integrated > in Fedora kernel before they hit mainline? Thanks, Dan. I was sent , http://www.mail-archive.com/linux-crypto@vger.kernel.org/msg15356.html Thanks,! Tried locally built kernel 4.2.0-0.rc2.git0.1.fc23 with up mentioned patches. Seems to boot fine, but in log appears: . . . mousedev: PS/2 mouse device common for all mice device-mapper: uevent: version 1.0.3 device-mapper: ioctl: 4.32.0-ioctl (2015-6-26) initialised: dm-devel powernv_idle_driver registered Using 'aes-generic' as fallback implementation. crypto_register_alg 'aes' = 0 Using 'aes-generic' as fallback implementation. Using 'cbc(p8_aes)' as fallback implementation. crypto_register_alg 'cbc(aes)' = 0 Using 'aes-generic' as fallback implementation. Using 'ctr(p8_aes)' as fallback implementation. alg: skcipher: Test 4 failed on encryption for p8_aes_ctr 00000000: 04 f3 d3 88 17 ef dc ef 8b 04 f8 3a 66 8d 1a 53 00000010: 57 1f 4b 23 e4 a0 af f9 69 95 35 98 8d 4d 8c c1 00000020: f0 b2 7f 80 bb 54 28 a2 7a 1b 9f 77 ec 0e 6e de 00000030: 57 1d d4 66 07 60 e1 80 08 24 3f 93 15 54 bb 2a 00000040: 9f 24 2b 17 92 60 05 68 21 74 a4 0a 28 eb 27 48 00000050: 90 50 37 ca 5c 0b 67 52 27 d2 7c 39 4b 85 35 0a 00000060: 23 90 a1 a0 79 8b 33 c0 73 d6 a0 9b fc 83 c9 f0 00000070: ef 23 22 19 16 6d e8 f4 b1 17 16 30 31 e8 a5 53 00000080: db 04 d8 bf 2e 75 9e 06 68 39 96 ec 38 1c 66 74 00000090: 7f e3 85 62 d5 1c da 83 86 63 07 41 f3 ce 2e c9 000000a0: 3a 6e d8 be bd f3 d7 26 a1 a3 c6 ad 6d 65 32 7b 000000b0: 6a 84 9c 11 1a b2 bc 0f a9 88 1e 4c 6b 36 52 ee 000000c0: eb 4d 79 9d d2 f6 af a9 8c 79 09 16 80 a4 25 9d 000000d0: e1 c5 e5 8e bf 4e cd 3f dd 2d f5 33 b8 ad 3d 2c 000000e0: a1 ac 58 7c 45 3f f7 18 4d 02 93 a1 53 f4 07 f4 000000f0: 4c 31 1e 3a 5b 7f 2d 0a d5 e1 6a eb 1d 55 47 29 00000100: ce 7b 1a 08 c6 62 1a a3 f1 bd 8e 05 7a 86 75 cd 00000110: a7 8e ba 3e 1b 9a ce 2e 10 4b 06 ce ed 5e 6f 77 00000120: 8e bc d0 08 40 2c 86 f2 6b 35 17 4d d7 b8 63 08 00000130: af d9 ed ca ad 5e 0b a4 d9 8e ff 8a d7 9f ae 1b 00000140: 11 1e 51 8e 98 22 09 99 2d ff a3 df 8a 38 76 5c 00000150: df 1a b1 79 2f 00 dc 39 42 d2 fe 0f 66 2b 75 72 00000160: 31 e0 59 34 2e 5a c6 51 3e 39 10 11 a6 42 48 34 00000170: 72 5b 16 8d b4 f8 92 e1 9c 84 34 48 2c db 20 38 00000180: ef 74 1b d1 71 f9 84 f7 17 0e df cc ec 13 80 a3 00000190: 7c 66 7c 2c 1e a4 09 8e ff 4a 19 b6 5f 6d fb 84 000001a0: 13 99 37 d1 b7 e6 36 06 a9 b8 40 39 46 25 56 eb 000001b0: 98 59 07 b2 80 95 fb 98 47 30 e1 8f be 7f c4 7e 000001c0: 77 8f 11 c9 b2 08 15 58 6c 57 20 c0 39 f8 5e f4 000001d0: 0d 91 dc 86 0f b5 99 09 d4 e2 8f a0 bf 83 99 b3 000001e0: c3 98 13 9c dc f7 ad 6a 1c 02 8e 45 43 da 3e c6 crypto_register_alg 'ctr(aes)' = 0 Failed to allocate transformation for 'ghash': -2 alg: hash: Failed to load transform for p8_ghash: -2 hidraw: raw HID events driver (C) Jiri Kosina usbcore: registered new interface driver usbhid usbhid: USB HID core driver drop_monitor: Initializing network drop monitor service ip_tables: (C) 2000-2006 Netfilter Core Team . . . Is it OK? Thanks! ------- Comment From leosilva.com 2015-07-14 12:44 EDT------- (In reply to comment #22) > Tried locally built kernel 4.2.0-0.rc2.git0.1.fc23 with up mentioned > patches. Seems to boot fine, but in log appears: > > . > . > . > mousedev: PS/2 mouse device common for all mice > device-mapper: uevent: version 1.0.3 > device-mapper: ioctl: 4.32.0-ioctl (2015-6-26) initialised: > dm-devel > powernv_idle_driver registered > Using 'aes-generic' as fallback implementation. > crypto_register_alg 'aes' = 0 > Using 'aes-generic' as fallback implementation. > Using 'cbc(p8_aes)' as fallback implementation. > crypto_register_alg 'cbc(aes)' = 0 > Using 'aes-generic' as fallback implementation. > Using 'ctr(p8_aes)' as fallback implementation. > alg: skcipher: Test 4 failed on encryption for p8_aes_ctr > 00000000: 04 f3 d3 88 17 ef dc ef 8b 04 f8 3a 66 8d 1a 53 > 00000010: 57 1f 4b 23 e4 a0 af f9 69 95 35 98 8d 4d 8c c1 > 00000020: f0 b2 7f 80 bb 54 28 a2 7a 1b 9f 77 ec 0e 6e de > 00000030: 57 1d d4 66 07 60 e1 80 08 24 3f 93 15 54 bb 2a > 00000040: 9f 24 2b 17 92 60 05 68 21 74 a4 0a 28 eb 27 48 > 00000050: 90 50 37 ca 5c 0b 67 52 27 d2 7c 39 4b 85 35 0a > 00000060: 23 90 a1 a0 79 8b 33 c0 73 d6 a0 9b fc 83 c9 f0 > 00000070: ef 23 22 19 16 6d e8 f4 b1 17 16 30 31 e8 a5 53 > 00000080: db 04 d8 bf 2e 75 9e 06 68 39 96 ec 38 1c 66 74 > 00000090: 7f e3 85 62 d5 1c da 83 86 63 07 41 f3 ce 2e c9 > 000000a0: 3a 6e d8 be bd f3 d7 26 a1 a3 c6 ad 6d 65 32 7b > 000000b0: 6a 84 9c 11 1a b2 bc 0f a9 88 1e 4c 6b 36 52 ee > 000000c0: eb 4d 79 9d d2 f6 af a9 8c 79 09 16 80 a4 25 9d > 000000d0: e1 c5 e5 8e bf 4e cd 3f dd 2d f5 33 b8 ad 3d 2c > 000000e0: a1 ac 58 7c 45 3f f7 18 4d 02 93 a1 53 f4 07 f4 > 000000f0: 4c 31 1e 3a 5b 7f 2d 0a d5 e1 6a eb 1d 55 47 29 > 00000100: ce 7b 1a 08 c6 62 1a a3 f1 bd 8e 05 7a 86 75 cd > 00000110: a7 8e ba 3e 1b 9a ce 2e 10 4b 06 ce ed 5e 6f 77 > 00000120: 8e bc d0 08 40 2c 86 f2 6b 35 17 4d d7 b8 63 08 > 00000130: af d9 ed ca ad 5e 0b a4 d9 8e ff 8a d7 9f ae 1b > 00000140: 11 1e 51 8e 98 22 09 99 2d ff a3 df 8a 38 76 5c > 00000150: df 1a b1 79 2f 00 dc 39 42 d2 fe 0f 66 2b 75 72 > 00000160: 31 e0 59 34 2e 5a c6 51 3e 39 10 11 a6 42 48 34 > 00000170: 72 5b 16 8d b4 f8 92 e1 9c 84 34 48 2c db 20 38 > 00000180: ef 74 1b d1 71 f9 84 f7 17 0e df cc ec 13 80 a3 > 00000190: 7c 66 7c 2c 1e a4 09 8e ff 4a 19 b6 5f 6d fb 84 > 000001a0: 13 99 37 d1 b7 e6 36 06 a9 b8 40 39 46 25 56 eb > 000001b0: 98 59 07 b2 80 95 fb 98 47 30 e1 8f be 7f c4 7e > 000001c0: 77 8f 11 c9 b2 08 15 58 6c 57 20 c0 39 f8 5e f4 > 000001d0: 0d 91 dc 86 0f b5 99 09 d4 e2 8f a0 bf 83 99 b3 > 000001e0: c3 98 13 9c dc f7 ad 6a 1c 02 8e 45 43 da 3e c6 > crypto_register_alg 'ctr(aes)' = 0 > Failed to allocate transformation for 'ghash': -2 > alg: hash: Failed to load transform for p8_ghash: -2 > hidraw: raw HID events driver (C) Jiri Kosina > usbcore: registered new interface driver usbhid > usbhid: USB HID core driver > drop_monitor: Initializing network drop monitor service > ip_tables: (C) 2000-2006 Netfilter Core Team > . > . > . > > Is it OK? > > Thanks! No, it's not OK. I also saw this. Seems to be a different bug in CTR selftest. We already open an internal bug for this issue. It's probably related with CTR counter is overflowing. It works for 48 bytes on self test but for the rest it's messed. IBM, is there any progress with the failed selfcheck and acceptance of the previous fixes in mainline kernel? We could probably disable VSX for a limited period in the Fedora kernels, but it also disables transactional memory support. ------- Comment From leosilva.com 2015-07-30 12:44 EDT------- (In reply to comment #24) > IBM, is there any progress with the failed selfcheck and acceptance of the > previous fixes in mainline kernel? We could probably disable VSX for a > limited period in the Fedora kernels, but it also disables transactional > memory support. From CTR we already fix it, although any patch was sent yet since GHASH issue is still in progress and I plan to send both. But it's a different issue and another bug was open to follow it. For VSX issue patches were accepted into cryptodev tree, but won't merged into upstream yet. These are the commit in this tree: crypto: vmx - Adding enable_kernel_vsx() to access VSX instructions 2d6f0600b2cd755959527230ef5a6fba97bb762a powerpc: Uncomment and make enable_kernel_vsx() routine available 72cd7b44bc99376b3f3c93cedcd052663fcdf705 Thanks for your support. In the interim until this lands we're disabled CRYPTO_DEV_VMX_ENCRYPT in F-23/rawhide so we can move forward. http://pkgs.fedoraproject.org/cgit/kernel.git/commit/?id=f2b1b300d36dbada5d9e94ee7f60abea94a244b0 ------- Comment From pfsmorigo.com 2015-08-11 16:18 EDT------- I updated my machine today to use f22 and hit the same issue. If I use kernel 4.1.3-201.fc22.ppc64le I have the same problem reported here. Leonidas' patches are already upstream so maybe we can do a backport to f22 as well, right? I've pushed this to F-22/21 so it will show up in the next kernel build, likely 4.1.7 ------- Comment From leosilva.com 2015-08-26 14:24 EDT------- Some additional patches that fixes bugs: http://git.kernel.org/cgit/linux/kernel/git/herbert/cryptodev-2.6.git/commit/?id=3c5f0ed78e976be705218cad62acf6a68e9d121e http://git.kernel.org/cgit/linux/kernel/git/herbert/cryptodev-2.6.git/commit/?id=1d4aa0b4c1816e8ca92a6aadb0d8f6b43c56c0d0 http://git.kernel.org/cgit/linux/kernel/git/herbert/cryptodev-2.6.git/commit/?id=73613a8159ddbf5a9ead0c03174458fa8210bdf7 We expect it makes kernel 4.3, since it's in next-tree. kernel-4.1.6-201.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-15130 kernel-4.1.6-201.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update kernel'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-15130 kernel-4.1.6-201.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report. kernel-4.1.7-100.fc21 has been submitted as an update to Fedora 21. https://bodhi.fedoraproject.org/updates/FEDORA-2015-15933 kernel-4.1.7-100.fc21 has been pushed to the Fedora 21 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update kernel'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-15933 kernel-4.1.7-100.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report. This was pushed stable, not sure why it wasn't closed arch/powerpc/Makefile:KBUILD_CFLAGS += $(call cc-option,-mno-vsx) |