Repository navigation
Many objtool warnings and kernel panic on boot #215
Description
At least since 4.15 (I stopped using this kernel after distrohopping around 4.12, but came back upon returning to Arch), building the kernel has resulted in a large amount of objtool warnings following the same format:
AR usr/built-in.o
AR arch/x86/crypto/built-in.o
CC [M] arch/x86/crypto/glue_helper.o
init/.tmp_main.o: warning: objtool: do_one_initcall()+0x38: sibling call from callable instruction with modified stack frame
CC init/do_mounts.o
CC init/do_mounts_initrd.o
AS [M] arch/x86/crypto/aes-x86_64-asm_64.o
CC [M] arch/x86/crypto/aes_glue.o
AS [M] arch/x86/crypto/des3_ede-asm_64.o
CC [M] arch/x86/crypto/des3_ede_glue.o
CC init/initramfs.o
init/.tmp_do_mounts.o: warning: objtool: name_to_dev_t()+0x292: sibling call from callable instruction with modified stack frame
AS [M] arch/x86/crypto/camellia-x86_64-asm_64.o
CC [M] arch/x86/crypto/camellia_glue.o
AS [M] arch/x86/crypto/blowfish-x86_64-asm_64.o
CC init/calibrate.o
CC arch/x86/events/core.o
AS arch/x86/entry/entry_64.o
init/.tmp_calibrate.o: warning: objtool: calibrate_delay()+0x330: sibling call from callable instruction with modified stack frame
CC init/init_task.o
AS arch/x86/entry/thunk_64.o
CC arch/x86/entry/syscall_64.o
CC arch/x86/entry/common.o
CC [M] arch/x86/crypto/blowfish_glue.o
CC init/version.o
arch/x86/events/.tmp_core.o: warning: objtool: x86_pmu_commit_txn()+0x8d: sibling call from callable instruction with modified stack frame
arch/x86/events/.tmp_core.o: warning: objtool: x86_pmu_add()+0x9e: sibling call from callable instruction with modified stack frame
arch/x86/events/.tmp_core.o: warning: objtool: perf_event_print_debug()+0x3d: sibling call from callable instruction with modified stack frame
arch/x86/events/.tmp_core.o: warning: objtool: perf_event_print_debug.cold.12()+0x46: return with modified stack frame
AS [M] arch/x86/crypto/twofish-x86_64-asm_64.o
Furthermore, the kernel crashes immediately with a kernel panic on boot. I lack enough experience with the kernel to know if these issues are related, but because both problems began at the same time, I can't help but assume so.
I have found related information on the Gentoo forums but it doesn't seem like the mentioned are applicable here.
Activity
zacharied commentedon Jun 12, 2018
For more information, the kernel panic log is as follows:
I am able to boot fine into vanilla Linux installed from the Arch repos as well as vanilla Linux built from source on this device, which leads me to believe that it is not a GRUB issue.
christianbundy commentedon Jun 12, 2018
I've had similar problems in the past that were resolved by one or both of the following:
mkinitcpio -g /boot/initramfs-linux-samus4.img -k /boot/vmlinuz-linux-samus4grub-mkconfig -o /boot/grub/grub.cfgWould you mind giving these a shot?
ehegnes commentedon Jun 13, 2018
Indeed, using an initramfs is one possible solution.
This is an issue of not having the proper drivers built into the kernel. This Gentoo wiki explains it well.
We should probably have AHCI (likely the core issue here) and all filesystem drivers built into the kernel in the default config rather than requiring an initramfs for the sake of better compatibility. The way I configure my Gentoo system, I would not use an initramfs at all if I weren't using full disk encryption.
EDIT: @zacharied So, if you don't want to opt for an initramfs, you could try enabling
CONFIG_SATA_AHCIas a built-in driver and ensure that whatever FS driver you use for the root FS is also built-in.christianbundy commentedon Jun 17, 2018
@ehegnes Do you think it might be worthwhile for us to add
CONFIG_SATA_AHCIto the default config to prevent the initramfs requirement?zacharied commentedon Jun 26, 2018
Sorry for the delay. Creating an initramfs as @christianbundy suggested indeed fixed the boot problems. The compilation warnings remain slightly unsettling though, along with the fact that compilation took upwards of an hour on my machine - could someone confirm that that's normal on a CBP2 LS? I could have sworn it was less than half that time last time I used this kernel.