Buildroot with x86_64 arch selected and kernels >=3.10 fails to boot on both qemu and virtualbox. Here is the kernel panic: [ 0.340000] [<ffffffff813d207f>] extract_buf+0x8f/0x120 [ 0.340000] [<ffffffff813d06be>] ? account+0x13e/0x180 [ 0.340000] [<ffffffff813d250b>] ? xfer_secondary_pool+0x1b/0x60 [ 0.340000] [<ffffffff813d219c>] extract_entropy+0x8c/0x1c0 [ 0.340000] [<ffffffff8131a149>] ? vsnprintf+0x109/0x580 [ 0.340000] [<ffffffff81f8520a>] ? tc_action_init+0x55/0x55 [ 0.340000] [<ffffffff81325121>] ? bucket_table_alloc+0x111/0x1b0 [ 0.340000] [<ffffffff813d2586>] get_random_bytes+0x36/0x70 [ 0.340000] [<ffffffff81325121>] bucket_table_alloc+0x111/0x1b0 [ 0.340000] [<ffffffff81f8520a>] ? tc_action_init+0x55/0x55 [ 0.340000] [<ffffffff81f8520a>] ? tc_action_init+0x55/0x55 [ 0.340000] [<ffffffff81325467>] rhashtable_init+0x1c7/0x3e0 [ 0.340000] [<ffffffff81f8526b>] netlink_proto_init+0x61/0x15d [ 0.340000] [<ffffffff810002c4>] do_one_initcall+0x84/0x1b0 [ 0.340000] [<ffffffff81f34fe7>] kernel_init_freeable+0x146/0x1d3 [ 0.340000] [<ffffffff818865d0>] ? rest_init+0x80/0x80 [ 0.340000] [<ffffffff818865d9>] kernel_init+0x9/0xf0 [ 0.340000] [<ffffffff818929d2>] ret_from_fork+0x42/0x70 [ 0.340000] [<ffffffff818865d0>] ? rest_init+0x80/0x80 [ 0.340000] Code: 55 8b 0f 44 8b 4f 10 44 8b 57 08 48 89 e5 41 57 41 56 41 55 41 54 89 c8 53 8b 5f 0c c1 c0 05 44 8b 47 04 45 8d a4 01 99 79 82 5a <44> 0f 38 f0 1e 89 d8 44 31 d0 44 89 1a 44 21 c0 41 c1 c8 02 31 [ 0.340000] RIP [<ffffffff8131531b>] sha_transform+0x2b/0x1110 [ 0.340000] RSP <ffff88007d3e7c90> I've tried different configuration, with various bootloaders, gcc, buildoot versions. At the same time, i386 architecture works just great.
Could you try: 1/ make clean 2/ make qemu_x86_64_defconfig 3/ make 4/ Follow the instructions in board/qemu/x86_64/readme.txt Thanks!
I have tried more different kernel version, and came to conclusion, that the first kernel version, where this issue appeared was 3.9. I have done bisection of linux kernel. Here is the linux kernel commit that breaks things: commit 83a57a4de1a222c351667ef9a0fedaac1295e85b Author: David Woodhouse <dwmw2@infradead.org> Date: Thu Dec 20 01:16:20 2012 +0000 x86: Enable ARCH_USE_BUILTIN_BSWAP With -mmovbe enabled (implicit with -march=atom), this allows the compiler to use the movbe instruction. This doesn't have a significant effect on code size (unlike on PowerPC), because the movbe instruction actually takes as many bytes to encode as a simple mov and a bswap. But for Atom in particular I believe it should give a performance win over the mov+bswap alternative. That was kind of why movbe was invented in the first place, after all... I've done basic functionality testing with IPv6 and Legacy IP, but no performance testing. The EFI firmware on my test box unfortunately no longer starts up. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Link: http://lkml.kernel.org/r/1355966180.18919.102.camel@shinybook.infradead.org Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 79795af..3e941aa 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -114,6 +114,7 @@ config X86 select MODULES_USE_ELF_RELA if X86_64 select CLONE_BACKWARDS if X86_32 select GENERIC_SIGALTSTACK + select ARCH_USE_BUILTIN_BSWAP config INSTRUCTION_DECODER def_bool y Revert this commit on later versions of kernel fix it. It seems, that this commit enables some functionality for atom processors, which was selected as arch variant in my case. Using your recommendations with "make qemu_x86_64_defconfig" command works as well. It seems that the reason is in atom arch variant.
Can you provide us with the config files you used? I tried to reproduce locally by using the qemu_x86_64_defconfig just adjusting optimization to atom and everything worked fine, on qemu 2.2.0 / ubuntu 15.04 However i do lack an atom, it was runtime-tested on a core m which i'd bet has all of the atom instructions plus a lot more.
Did you specify explicitly a CPU model to be emulated by Qemu using the -cpu option? If you don't, my understanding is that it will emulate a CPU similar to the host CPU (but I'm not sure about this). In any case, if your Qemu was emulating something that didn't support the movbe instruction, then it would break exactly like it did for you. Can you please check your Qemu setup ? Also, old versions of Qemu were not properly emulating the n270 (which is the Qemu speak for Atom), and were precisely not emulating the movbe instruction: https://lists.gnu.org/archive/html/qemu-devel/2013-02/msg01201.html. So my bet is really an emulation issue on your side. I've looked at the kernel, and the ARCH_USE_BUILTIN_BSWAP option has not been removed since commit 83a57a4de1a222c351667ef9a0fedaac1295e85b, so I believe that this kernel commit has since then been widely tested, and that it is correct. I'll mark the bug as "works for me". Please do not hesitate to re-open with more details about your Qemu setup (version, and which -cpu option you've used) if you can still reproduce the problem. Thanks!