On Mon, Mar 13, 2017 at 07:06:01PM +0200, Krzysztof Kozlowski wrote:
>
> I bisected this to commit f1c131b45410 ("crypto: xts - Convert to
> skcipher"). The s5p-sss driver stays the same... but the xts changes and
> as a result we have a NULL pointer dereference (actually of value
> 0004):
> [
On Mon, Mar 13, 2017 at 07:06:01PM +0200, Krzysztof Kozlowski wrote:
>
> I bisected this to commit f1c131b45410 ("crypto: xts - Convert to
> skcipher"). The s5p-sss driver stays the same... but the xts changes and
> as a result we have a NULL pointer dereference (actually of value
> 0004):
>
On Sun, Mar 12, 2017 at 09:13:22PM +0200, Krzysztof Kozlowski wrote:
> On Fri, Mar 10, 2017 at 03:44:45PM -0600, Nathan Royce wrote:
> > Sure, I went ahead and rebuilt it just using the bare exynos_defconfig
> > and adding XTS and ECB and no other changes.
> >
> > No flags were used. No patches
On Fri, Mar 10, 2017 at 03:44:45PM -0600, Nathan Royce wrote:
> Sure, I went ahead and rebuilt it just using the bare exynos_defconfig
> and adding XTS and ECB and no other changes.
>
> No flags were used. No patches were used other than the 2 you
> provided. Just the barest of bears, the barest
Sure, I went ahead and rebuilt it just using the bare exynos_defconfig
and adding XTS and ECB and no other changes.
No flags were used. No patches were used other than the 2 you
provided. Just the barest of bears, the barest of bones, the barest of
deserts, the barest of hairless cats.
I also
On Thu, Mar 09, 2017 at 05:16:35AM -0600, Nathan Royce wrote:
> Gave it a try on 4.10.1, but still to no avail:
(...)
> Also for the sake of testing, I did not add any FLAGS for compilation this
> time.
Damn, I am fixing bugs around but not the one you are hitting. Can you
also check if
Gave it a try on 4.10.1, but still to no avail:
*
[8.516138] raid6: using intx1 recovery algorithm
[ [0;32m OK [0m] Started Flush Journal to Persistent Storage.
[9.692091] Unable to handle kernel NULL pointer dereference at
virtual address 0004
[9.698896] pgd = c0004000
[
On Wed, Mar 08, 2017 at 07:45:42PM +0200, Krzysztof Kozlowski wrote:
> On Mon, Mar 06, 2017 at 03:29:48PM -0600, Nathan Royce wrote:
> > OK, I just tried 4.10.0 and the output is looking the same.
> >
> > I can't say my setup is all that odd. The cryptographic use is only
> > with the swap
On Mon, Mar 06, 2017 at 03:29:48PM -0600, Nathan Royce wrote:
> OK, I just tried 4.10.0 and the output is looking the same.
>
> I can't say my setup is all that odd. The cryptographic use is only
> with the swap partition found in my original email (seen in Herbert's
> reply).
You have quite
OK, I just tried 4.10.0 and the output is looking the same.
I can't say my setup is all that odd. The cryptographic use is only
with the swap partition found in my original email (seen in Herbert's
reply).
My normal build goes as such:
1) git clean -xdf
2) git reset --hard
3) curl
On Mon, Mar 06, 2017 at 10:18:45AM -0600, Nathan Royce wrote:
> I tried the patch you submitted, however it also fails for the most part.
>
> "For the most part" because "xts" is now found.
> $ grep xts /proc/crypto
> name : xts(aes)
> driver : xts(ecb-aes-s5p)
Ah, so probably I
I tried the patch you submitted, however it also fails for the most part.
"For the most part" because "xts" is now found.
$ grep xts /proc/crypto
name : xts(aes)
driver : xts(ecb-aes-s5p)
Fail:
*
[ 21.057756] xor: using function: neon (352.000 MB/sec)
[ 21.064243] Unable to
On Fri, Mar 03, 2017 at 12:02:10PM +0800, Herbert Xu wrote:
> On Thu, Mar 02, 2017 at 05:35:30PM -0600, Nathan Royce wrote:
> > ARM ODroid XU4
> >
> > $ cat /proc/config.gz | gunzip | grep XTS
> > CONFIG_CRYPTO_XTS=y
> >
> > $ grep xts /proc/crypto
> > //4.9.13
> > name : xts(aes)
> >
Yup, when I disabled the s5p driver, xts DID show in the /proc/crypto list.
Heh, I was about to ask if it was something I should push towards
another maintainer for s5p stuff, but found you listed in that as
well.
If I am incorrect in that assumption, do let me know whom else I
should make aware
On Fri, Mar 03, 2017 at 04:36:18AM -0600, Nathan Royce wrote:
> I do have ECB selected as well:
> DM_CRYPT=y
> CRYPTO_ECB=y
> CRYPTO_XTS=y
>
> name : ecb(aes)
> driver : ecb-aes-s5p
> module : kernel
> priority : 100
> refcnt : 1
> selftest : passed
> internal
I do have ECB selected as well:
DM_CRYPT=y
CRYPTO_ECB=y
CRYPTO_XTS=y
name : ecb(aes)
driver : ecb-aes-s5p
module : kernel
priority : 100
refcnt : 1
selftest : passed
internal : no
type : ablkcipher
async: yes
blocksize: 16
min keysize :
On Fri, Mar 03, 2017 at 03:00:26AM -0600, Nathan Royce wrote:
> OK, I went ahead and enabled self tests
> "CRYPTO_MANAGER_DISABLE_TESTS=n", and my system was able to boot,
> albeit with failures:
> *
> Mar 02 23:14:38 server kernel: ---[ end trace 1c8a91f28cbcebf3 ]---
> Mar 02 23:14:38 server
OK, I went ahead and enabled self tests
"CRYPTO_MANAGER_DISABLE_TESTS=n", and my system was able to boot,
albeit with failures:
*
Mar 02 23:14:38 server kernel: ---[ end trace 1c8a91f28cbcebf3 ]---
Mar 02 23:14:38 server kernel: alg: skcipher: encryption failed on
test 1 for xts(ecb-aes-s5p):
On Thu, Mar 02, 2017 at 05:35:30PM -0600, Nathan Royce wrote:
> ARM ODroid XU4
>
> $ cat /proc/config.gz | gunzip | grep XTS
> CONFIG_CRYPTO_XTS=y
>
> $ grep xts /proc/crypto
> //4.9.13
> name : xts(aes)
> driver : xts(aes-generic)
> //4.10.1
>
> //cbc can be found though
>
>
19 matches
Mail list logo
