kernel 4.17rc cycle problem with x86_64 builds

[Mauro Rossi]

Hi,
while testing x86_64 oreo-x86 build with recent kernels

I encountered a problem, with all 4.17 release candidates;
x86 32bit build is ok, but x86_64 kernel freezes in the early stage of boot.

Has someone seen this issue and do you know how to solve?

Mauro

[Guneet Atwal]

Yup , same here i get a kernel panic as soon as i hit the option in grub menu.

--
You received this message because you are subscribed to the Google Groups "Android-x86" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.
To post to this group, send email to andro...@googlegroups.com.
Visit this group at https://groups.google.com/group/android-x86.
For more options, visit https://groups.google.com/d/optout.

[youling 257]

what problem？

在 2018年5月22日星期二 UTC+8下午1:02:17，Mauro Rossi写道：

[Mauro Rossi]

Il giorno martedì 22 maggio 2018 10:32:31 UTC+2, youling 257 ha scritto:

what problem？

On Lenovo T460 I cannot pass the initial txt boot screen and laptop stays frozen

Could you send me your kernel sources repo link and x86_64 defconfig files, I will use kdiff to check how they differ from mine.

Thanks youling 257

Mauro

[youling 257]

https://github.com/youling257/android-4.9/commits/experimental/android-mainline-4.17-tracking

在 2018年5月23日星期三 UTC+8上午1:57:13，Mauro Rossi写道：

[Guneet Atwal]

i am still getting stuck on boot when trying 4.17rc6 kernel , everything else is stock oreo-x86. Can you tell me if i need to make any change in the device tree or something else ?

[youling 257]

 see "GRUB _" on the top left of the screen (the underscore seems like a blinking cursor), and hitting keys does nothing.

yes，4.17 kernel have this problem

[Guneet Atwal]

also how did you compile mesa 18.1.0 ? when i try that i get error that LLVMAddEarlyCSEMemSSAPass is undefined or when i use LLVM 60 i get  unrecognized module type "llvm_tblgen"

[Guneet Atwal]

looks to me like a clang error , maybe i need updated version ?

[Mauro Rossi]

Il giorno venerdì 25 maggio 2018 09:48:58 UTC+2, Guneet Atwal ha scritto:

also how did you compile mesa 18.1.0 ? when i try that i get error that LLVMAddEarlyCSEMemSSAPass is undefined or when i use LLVM 60 i get  unrecognized module type "llvm_tblgen"

You need llvm 5.0 or 6.0 "side-build", here follows llvm60 commands for oreo-x86 and nougat-x86:

cd ~/oreo-x86/external

git clone https://github.com/maurossi/llvm llvm60

cd ~/oreo-x86/external/llvm60

git fetch origin oreo-x86_llvm60

git checkout FETCH_HEAD

git remote add llvm-mirror https://github.com/llvm-mirror/llvm

git fetch llvm-mirror release_60

git rebase llvm-mirror/release_60

cd ~/oreo-x86/external/mesa

git reset --hard

git remote add maurossi https://github.com/maurossi/mesa

git fetch maurossi 18.1.0_oreo-x86

git checkout FETCH_HEAD

git apply 0001-DO-NOT-MERGE-android-build-mesa-with-llvm60.patch

[or alternatively for mesa 18.2.0devel]

cd ~/oreo-x86/external/mesa

git reset --hard

git remote add maurossi https://github.com/maurossi/mesa

git fetch maurossi 18.2.0devel_w21

git checkout FETCH_HEAD

git apply 0001-DO-NOT-MERGE-android-build-mesa-with-llvm60.patch

NOTE: if you are building nougat-x86, you will need to checkout x86 oreo-x86 branch of external/libdrm project,

which is modified to install libdrm in /vendor/lib - This step is not necessary if you are building oreo-x86

cd ~/nougat-x86/external/libdrm/

git fetch x86 oreo-x86

git checkout FETCH_HEAD

cd ~/nougat-x86/external

git clone https://github.com/maurossi/llvm llvm60

cd ~/nougat-x86_kernel/external/llvm60

git fetch origin nougat-x86_llvm60

git checkout FETCH_HEAD

git remote add llvm-mirror https://github.com/llvm-mirror/llvm

git fetch llvm-mirror release_60

git rebase llvm-mirror/release_60

cd ~/nougat-x86/external/mesa

git reset --hard

git remote add maurossi https://github.com/maurossi/mesa

git fetch maurossi 18.1.0_oreo-x86

git checkout FETCH_HEAD

git apply 0001-DO-NOT-MERGE-android-build-mesa-with-llvm60.patch

[or alternatively for mesa 18.2.0devel]

cd ~/nougat-x86/external/mesa

git reset --hard

git remote add maurossi https://github.com/maurossi/mesa

git fetch maurossi 18.2.0devel_w21

git checkout FETCH_HEAD

git apply 0001-DO-NOT-MERGE-android-build-mesa-with-llvm60.patch

[Guneet Atwal]

can you tell me why my kernel 4.17rc6 32bit build with mesa 18.0.4 is working fine on my old core i3 laptop and not on my cherry trail z8350 laptop ? it boots fine and then i only see terminal. No bootanimation nothing.

[Mauro Rossi]

I forgot that also for external/drm_gralloc is nececessary in case you build nougat-x86,

but I suppose, since you booted on Core i3, that you are using oreo-x86 latest repo update.

Il giorno sabato 26 maggio 2018 12:32:00 UTC+2, Guneet Atwal ha scritto:

can you tell me why my kernel 4.17rc6 32bit build with mesa 18.0.4 is working fine on my old core i3 laptop and not on my cherry trail z8350 laptop ? it boots fine and then i only see terminal. No bootanimation nothing.

It was reported in the past past that that cherry trail is problematic

dmesg, logcat are needed to analyze what prevents SurfaceFlinger showing the GUI

Could you please provide yours?

Thanks

[Mauro Rossi]

Il giorno giovedì 24 maggio 2018 16:39:36 UTC+2, youling 257 ha scritto:

 see "GRUB _" on the top left of the screen (the underscore seems like a blinking cursor), and hitting keys does nothing.

yes，4.17 kernel have this problem

Now x86_64 kernel 4.17rc7 freezes a little bit later with following trace (pictures only)

Mauro

[youling 257]

I don't have this problem，i have never see this problem.

在 2018年5月28日星期一 UTC+8上午6:10:32，Mauro Rossi写道：

[spin877]

gcmaes_crypt_by_sg è stata inserita il 18 febbraio prova a chiedere a chi ha proposto la patch.

[Guneet Atwal]

when i try to build using llvm60 and mesa 18.1.0 then i get this error

error: undefined reference to 'llvm::initializeX86FlagsCopyLoweringPassPass(llvm::PassRegistry&

external/llvm60/lib/Target/X86/X86TargetMachine.cpp:420: error: undefined reference to 'llvm::createX86FlagsCopyLoweringPass()'

Any idea what i might be missing here

On Saturday, May 26, 2018 at 4:50:37 AM UTC+5:30, Mauro Rossi wrote:

[Mauro Rossi]

Il giorno giovedì 14 giugno 2018 12:17:40 UTC+2, Guneet Atwal ha scritto:

when i try to build using llvm60 and mesa 18.1.0 then i get this error

error: undefined reference to 'llvm::initializeX86FlagsCopyLoweringPassPass(llvm::PassRegistry&

external/llvm60/lib/Target/X86/X86TargetMachine.cpp:420: error: undefined reference to 'llvm::createX86FlagsCopyLoweringPass()'

I did not see this error when building mesa 18.1.0,

please try to checkout oreo-x86_llvm60 without doing the rebase to llvm-mirror/release_60, which may have changed/evolved

cd ~/oreo-x86/external

git clone https://github.com/maurossi/llvm llvm60

cd ~/oreo-x86/external/llvm60

git fetch origin oreo-x86_llvm60

git checkout FETCH_HEAD

git remote add llvm-mirror https://github.com/llvm-mirror/llvm

#git fetch llvm-mirror release_60

#git rebase llvm-mirror/release_60

As an alternative, you could use the updated oreo-x86_llvm70 branch, but in that case you need to change external/mesa/Android.mk accordingly with attached patch

cd ~/oreo-x86/external

git clone https://github.com/maurossi/llvm llvm70

cd ~/oreo-x86/external/llvm70

git fetch origin oreo-x86_llvm70

git checkout FETCH_HEAD

[zjaro]

Thanks man , rebasing llvm-mirror was causing the issue. Can you tell me how to add gapps in the ROM ? cause when i use open gapps it gives me crashes. Same happens even in nougat x86 . But there are no crashes in official release builds. Thanks in advance.

[yuki haya]

Hello.

I also have similar problems.

Hang after initrd.

I tried it in various environments.

The only thing that started was when Nested Paging was disabled in VirtualBox.

In other words, is there a problem with managing memory space?

Thank you.

= Yuki =

[youling 257]

https://github.com/torvalds/linux/commit/52e1cf2d19c2e62e6a81b8de3f7320d033917dd5

it fixed my Bay trail problem，bay trail 32bit uefi，running 64bit kernel.

[yuki haya]

Hello.

Does the behavior of kernel 4.16 or later Native Bridge behave differently?

There is a problem that the application does not start up.

logcat has an error on libEGL.so.

Thank you.

[youling 257]

you can test 7.1 rc2 and r1 use 7_y/z houdini running 王者荣耀，

4.9、4.10、4.11、4.12、4.13、4.14、4.15、4.16、4.17、4.18，all need Revert "x86/signal/64: Re-add support for SS in the 64-bit signal context"，I say this patch，android-x86: fix 64bit android7.1 games crash，From: lixin <li...@phoenixos.com>，Date: Sat, 8 Apr 2017 20:06:45 +0800

openthos kernel 4.9、4.14、4.15、4.16、4.17、4.18 has a Revert "x86/signal/64: Re-add support for SS in the 64-bit signal context" patch by cwhuang，fix 5_y/z houdini with high kernel version，this patch added to Androidx86 7.1 r2 kernel 4.9.

在 2018年7月7日星期六 UTC+8下午8:32:23，yuki haya写道：

[youling 257]

https://github.com/PhoenixOS/kernel/commits/phoenix-4.9/arch/x86/kernel/signal.c

https://github.com/youling257/android-4.9/commits/experimental/android-mainline-4.15-tracking/arch/x86/kernel/signal.c

https://github.com/youling257/android-4.9/commits/experimental/android-mainline-4.16-tracking/arch/x86/kernel/signal.c

https://github.com/youling257/android-4.9/commits/experimental/android-mainline-4.17-tracking/arch/x86/kernel/signal.c

https://github.com/youling257/openthos-kernel/commits/openthos-4.9.31/arch/x86/kernel/signal.c

https://github.com/youling257/openthos-kernel/commits/openthos-4.18/arch/x86/kernel/signal.c

https://github.com/youling257/openthos-kernel/commits/openthos-4.17/arch/x86/kernel/signal.c

https://github.com/youling257/openthos-kernel/commits/openthos-4.16/arch/x86/kernel/signal.c

[Mauro Rossi]

Hi,

thanks a lot

Do you see some kind of freeze happening with 4.18rc expecially with Intel manufactured chipsets?

My builds with kernel 4.17 and 4.18rc are still not reaching the console they freeze when autoloading some kernel module

Mauro

[tristin....@gmail.com]

I am also attempting to a build with kernel 4.17 and 4.18 and am failing to boot completely. Always, the last message I see printed to the console is:

random: crng init done

It takes between 30 seconds and 5 minutes for this message to appear. That time can be cut down if I randomly press keys on a keyboard, thereby increasing entropy. I've attempted to boot two different machines, a SandyBridge desktop and a Broadwell tablet, and received the same result.

I see that experimental-android-4.17 has been tagged at https://android.googlesource.com/kernel/common/+/experimental-android-4.17, so my next step will be to roll patches from the maurossi branch into experimental-android-4.17 and try again.

[Mauro Rossi]

Hi,

Il giorno martedì 10 luglio 2018 02:53:58 UTC+2, tristin....@gmail.com ha scritto:

I am also attempting to a build with kernel 4.17 and 4.18 and am failing to boot completely. Always, the last message I see printed to the console is:

random: crng init done

It takes between 30 seconds and 5 minutes for this message to appear. That time can be cut down if I randomly press keys on a keyboard, thereby increasing entropy. I've attempted to boot two different machines, a SandyBridge desktop and a Broadwell tablet, and received the same result.

Thanks for the info, the problem is described here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897572#82

I will try with simple and unsafe approach of 43838a23a05f ("random: fix crng_ready() test")

 

I see that experimental-android-4.17 has been tagged at https://android.googlesource.com/kernel/common/+/experimental-android-4.17, so my next step will be to roll patches from the maurossi branch into experimental-android-4.17 and try again.

On Monday, 9 July 2018 03:33:26 UTC-4, Mauro Rossi wrote:

Hi,

thanks a lot

Do you see some kind of freeze happening with 4.18rc expecially with Intel manufactured chipsets?

My builds with kernel 4.17 and 4.18rc are still not reaching the console they freeze when autoloading some kernel module

Mauro

Il giorno sabato 7 luglio 2018 18:32:18 UTC+2, youling 257 ha scritto:

you can test 7.1 rc2 and r1 use 7_y/z houdini running 王者荣耀，

4.9、4.10、4.11、4.12、4.13、4.14、4.15、4.16、4.17、4.18，all need Revert "x86/signal/64: Re-add support for SS in the 64-bit signal context"，I say this patch，android-x86: fix 64bit android7.1 games crash，From: lixin <li...@phoenixos.com>，Date: Sat, 8 Apr 2017 20:06:45 +0800

openthos kernel 4.9、4.14、4.15、4.16、4.17、4.18 has a Revert "x86/signal/64: Re-add support for SS in the 64-bit signal context" patch by cwhuang，fix 5_y/z houdini with high kernel version，this patch added to Androidx86 7.1 r2 kernel 4.9.

在 2018年7月7日星期六 UTC+8下午8:32:23，yuki haya写道：

Hello.

Does the behavior of kernel 4.16 or later Native Bridge behave differently?

There is a problem that the application does not start up.

logcat has an error on libEGL.so.

Thank you.

Hi youling257,

at the moment I do not see improvements with  Revert "x86/signal/64: Re-add support for SS in the 64-bit signal context", but maybe my testing scope was too restricted (VulkanCapsViewer)

Have you seen improvements?

In which specific arm only application?

Mauro

[Mauro Rossi]

minor editing correction

43838a23a05f ("random: fix crng_ready() test") needs to be Reverted

Mauro

Il giorno mercoledì 11 luglio 2018 19:09:41 UTC+2, Mauro Rossi ha scritto:

Hi,

Il giorno martedì 10 luglio 2018 02:53:58 UTC+2, tristin....@gmail.com ha scritto:

I am also attempting to a build with kernel 4.17 and 4.18 and am failing to boot completely. Always, the last message I see printed to the console is:

random: crng init done

It takes between 30 seconds and 5 minutes for this message to appear. That time can be cut down if I randomly press keys on a keyboard, thereby increasing entropy. I've attempted to boot two different machines, a SandyBridge desktop and a Broadwell tablet, and received the same result.

Thanks for the info, the problem is described here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897572#82

I will try with simple and unsafe approach of Reverting 43838a23a05f ("random: fix crng_ready() test")

[youling 257]

nougat 7_y/z houdini 王者荣耀，http://dlied5.myapp.com/myapp/1104466820/sgame/2017_com.tencent.tmgp.sgame_h170_1.35.1.10_d756be.apk

在 2018年7月12日星期四 UTC+8上午1:11:34，Mauro Rossi写道：

[youling 257]

my problem is this，[tip:efi/urgent] efi/x86: Fix mixed mode reboot loop by removing ...，efi/x86: remove pointless call to PciIo->Attributes，LKML: Ard Biesheuvel: Re: [GIT PULL 0/1] EFI mixed mode fix for v4.18

https://patchwork.kernel.org/patch/10519375/ https://lkml.org/lkml/2018/7/11/190 http://patches.linaro.org/patches/307/

mixed EFI mode Bay Trail tablet

would not boot at all any more, but enter a reboot loop without

any logs printed by the kernel.

在 2018年7月2日星期一 UTC+8下午4:49:21，youling 257写道：

[spin877]

I tried a compile android-x86 7.1.2 with kernel openthos-4.18 

He gave me an error:

RIP: 0010:aesni_gcm_init+0x89/0x30f

I had to disable the CONFIG_CRYPTO_AES_NI_INTEL module

on my Baytrail efi32 tablet the kernel was blocked immediately

[youling 257]

Hope to find the problem right direction.

/* Copy trampoline code in place */

 memcpy(trampoline_32bit + TRAMPOLINE_32BIT_CODE_OFFSET / sizeof(unsigned long),

   &trampoline_32bit_src, TRAMPOLINE_32BIT_CODE_SIZE);

https://lkml.org/lkml/2018/7/3/574

https://lkml.org/lkml/2018/7/3/1028

https://patchwork.kernel.org/patch/10507261/

[Mauro Rossi]

Hi, 

Il giorno martedì 10 luglio 2018 02:53:58 UTC+2, tristin....@gmail.com ha scritto:

I am also attempting to a build with kernel 4.17 and 4.18 and am failing to boot completely. Always, the last message I see printed to the console is:

random: crng init done

It takes between 30 seconds and 5 minutes for this message to appear. That time can be cut down if I randomly press keys on a keyboard, thereby increasing entropy. I've attempted to boot two different machines, a SandyBridge desktop and a Broadwell tablet, and received the same result.

In order to avoid the wait (or freeze) happening because of random, enabling CONFIG_HW_RANDOM as builtin helps

In some other project kernel the CONFIG_HW_RANDOM* are all enabled and in principle they should do no harm.

Now, the only remaining problem is that for me it works only for x86 32bit kernel,

but at least I can boot with one of the two targets.

Mauro

CONFIG_HW_RANDOM=y

CONFIG_HW_RANDOM_TIMERIOMEM=y

CONFIG_HW_RANDOM_INTEL=y

CONFIG_HW_RANDOM_AMD=y

CONFIG_HW_RANDOM_VIA=y

CONFIG_HW_RANDOM_VIRTIO=y

[Mauro Rossi]

Hi, kind request for help.

Does some one know, after having enabled the CONFIG_HW_RANDOM* stuff, 

what is still causing the problem with booting 64 bit kernels from 4.17 to 4.18rc6?

It would be nice to solve this problem once and forever, 

to be able to boot and solve the other problems too. :-)

Mauro

[spin877]

oreo-x86_64 kernel https://github.com/youling257/openthos-kernel/commits/openthos-4.18 rc-3 BayTrail efi32

I have to add these patches to start on my tablet.

diff --git a/arch/x86/configs/android-x86_64_defconfig b/arch/x86/configs/android-x86_64_defconfig

index d60742c..fc6cfc5 100644

--- a/arch/x86/configs/android-x86_64_defconfig

+++ b/arch/x86/configs/android-x86_64_defconfig

+# CONFIG_CRYPTO_AES_NI_INTEL is not set

diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c

index c7ece76..0df1388 100644

--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c

+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c

@@ -301,7 +301,7 @@ static void ttm_bo_vm_open(struct vm_area_struct *vma)

        struct ttm_buffer_object *bo =

            (struct ttm_buffer_object *)vma->vm_private_data;

 

-       WARN_ON(bo->bdev->dev_mapping != vma->vm_file->f_mapping);

+//  WARN_ON(bo->bdev->dev_mapping != vma->vm_file->f_mapping);

 

        (void)ttm_bo_reference(bo);

 }

diff --git a/drivers/i2c/busses/i2c-designware-baytrail.c b/drivers/i2c/busses/i2c-designware-baytrail.c

index dbda8c9..2d3c4f2 100644

--- a/drivers/i2c/busses/i2c-designware-baytrail.c

+++ b/drivers/i2c/busses/i2c-designware-baytrail.c

@@ -128,7 +128,7 @@ static int baytrail_i2c_acquire(struct dw_i2c_dev *dev)

        else

                dev_err(dev->dev, "PUNIT SEM: %d\n", sem);

 

-       WARN_ON(1);

+//  WARN_ON(1);

 

        return -ETIMEDOUT;

 }

diff --git a/fs/buffer.c b/fs/buffer.c

index cabc045..3fb0528 100644

--- a/fs/buffer.c

+++ b/fs/buffer.c

@@ -1133,7 +1133,7 @@ void __brelse(struct buffer_head * buf)

                put_bh(buf);

                return;

        }

-       WARN(1, KERN_ERR "VFS: brelse: Trying to free free buffer\n");

+//  WARN(1, KERN_ERR "VFS: brelse: Trying to free free buffer\n");

 }

 EXPORT_SYMBOL(__brelse);

 

with quemu, also, with these patches, it does not work

[youling 257]

git init

git remote add openthos https://mirrors.tuna.tsinghua.edu.cn/git/openthos-src/kernel/common

git fetch openthos

git checkout openthos-4.18

git checkout openthos-4.17

…………

…………

[youling 257]

it's wrong，no any help at all.

在 2018年7月13日星期五 UTC+8上午12:04:26，youling 257写道：

[youling 257]

it's wrong，no any help at alll for me.

在 2018年7月2日星期一 UTC+8下午4:49:21，youling 257写道：

https://github.com/torvalds/linux/commit/52e1cf2d19c2e62e6a81b8de3f7320d033917dd5

[youling 257]

I use gcc 8 build Linux kernel，i needn't Android source and Android toolchain，i use time make targz-pkg -i command . Linux version 4.18.0-rc6-android-x86_64+ (root@localhost) (gcc version 8.1.0 (Ubuntu 8.1.0-12ubuntu1)) #2 SMP PREEMPT Fri Jul 27 22:24:34 CST 2018

a lot of bisect to find problem reason，https://www.spinics.net/lists/linux-efi/msg14445.html ，Temporary solution，Revert "x86/boot/compressed/64: Set up trampoline memory"，https://github.com/youling257/android-4.9/commits/experimental/android-mainline-4.18-tracking

https://lkml.org/lkml/2018/7/27/648

https://lkml.org/lkml/diff/2018/7/27/648/1

this patch final solved my problem.

在 2018年7月17日星期二 UTC+8上午2:39:51，youling 257写道：

[Mauro Rossi]

Hi youling257,

Il giorno sabato 28 luglio 2018 04:13:12 UTC+2, youling 257 ha scritto:

I use gcc 8 build Linux kernel，i needn't Android source and Android toolchain，i use time make targz-pkg -i command . Linux version 4.18.0-rc6-android-x86_64+ (root@localhost) (gcc version 8.1.0 (Ubuntu 8.1.0-12ubuntu1)) #2 SMP PREEMPT Fri Jul 27 22:24:34 CST 2018

a lot of bisect to find problem reason，https://www.spinics.net/lists/linux-efi/msg14445.html ，Temporary solution，Revert "x86/boot/compressed/64: Set up trampoline memory"，https://github.com/youling257/android-4.9/commits/experimental/android-mainline-4.18-tracking

https://lkml.org/lkml/2018/7/27/648

https://lkml.org/lkml/diff/2018/7/27/648/1

this patch final solved my problem.

Do you meant that that patch solves you problem with u32k64 android-x86 builds

or that also solves default x86_64 iso kernel freeze/panic?

Thanks

Mauro

[youling 257]

as i know，my problem won't happen on gcc 4.6，you no this problem. https://lkml.org/lkml/2018/4/16/1097 ，maurossi@ANDROIDDEV) (gcc version 4.6 20120106，cwhuang@android-x86) (gcc version 4.6 20120106

from begin，we are talk different problem，my problem made me very angry，unbearable，until i have to do git bisect.

why you not do git bisect to find the bad one commit ?

在 2018年7月29日星期日 UTC+8上午1:05:19，Mauro Rossi写道：

[Mauro Rossi]

Hi,

Because with my manual setup it could take ages, I don't know how to automate, 

are there documented ways?

Mauro

 

[Mauro Rossi]

Hi, 

I have found what was causing the problem with 64bit kernel freezing in both virtuamachines and physical

[    0.984004] RIP: 0010:aesni_gcm_init+0x89/0x30f

[    0.984832] Code: 0f 6f ca 66 0f 73 fa 08 66 0f 73 d9 08 66 0f eb da 66 0f 70 d1 24 66 0f 76 15 33 11 03 01 66 0f db 15 1b 11 03 01 66 0f ef da <66> 0f 7f 5e 60 66 0f 6f eb 66 0f 70 cb 4e 66 0f ef cb 66 0f 7f 8e 

[    0.987813] RSP: 0000:ffff90924132f7d8 EFLAGS: 00010246

[    0.988818] RAX: ffff90924132fb98 RBX: 0000000000000010 RCX: ffff8d3ddd93fc50

[    0.989979] RDX: ffff90924132fb98 RSI: ffff90924132f8c8 RDI: ffff8d3ddd93fc60

[    0.991171] RBP: 0000000000000000 R08: ffff8d3dde3e4000 R09: 0000000000000008

[    0.992349] R10: ffff8d3e5e9ad000 R11: 0000000000000000 R12: ffff8d3ddd93fc50

[    0.993424] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000008

[    0.994491] FS:  0000000000000000(0000) GS:ffff8d3de3d80000(0000) knlGS:0000000000000000

[    0.996428] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033

[    0.997315] CR2: 0000000000000000 CR3: 000000003000a001 CR4: 00000000000606e0

[    0.998395] note: cryptomgr_test[939] exited with preempt_count 2

then I found this:

https://www.spinics.net/lists/linux-crypto/msg23319.html

then I changed the kernel config like this:

-# CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set

+CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y

and now I can proceed in boot with 64bit kernel

Mauro

[Mauro Rossi]

Hi Youling,

I've bisected the cryptomgr_test crash and panic with 64bit kernel to this first bad commit:

1476db2d129d5e4fc59e93a7abd22edcb26b52f5

"crypto: aesni - Move HashKey computation from stack to gcm_context"

and informed the developer about the crash

Mauro