Many objtool warnings and kernel panic on boot

[zacharied]

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.

[zacharied]

For more information, the kernel panic log is as follows:

[   0.213356] dw_dmac INTL9C60:00: Missing DT data
[   0.386275] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[   0.386349] Kernel Offset: 0x2d000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[   0.386414] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

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]

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-samus4
• grub-mkconfig -o /boot/grub/grub.cfg

Would you mind giving these a shot?

[ehegnes]

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_AHCI as a built-in driver and ensure that whatever FS driver you use for the root FS is also built-in.

[christianbundy]

@ehegnes Do you think it might be worthwhile for us to add CONFIG_SATA_AHCI to the default config to prevent the initramfs requirement?

[zacharied]

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.