Kernel 5.15 does not boot when built with CONFIG_MPILEDRIVER=y about kernel_compiler_patch HOT 24 CLOSED

@drfiemost - Nice, thanks for pointing that out. Totally slipped my mind.

Can one of you guys please try af5c6eb from my test branch to verify functionality? I successfully built 5.15.2 (MPILEDRIVER) but cannot boot it without the hardware.

Further, I am unclear if the syntax is:

1. As I included in the commit (mixing the old $(call cc-option,-mno-tbm) or
2. Straight up += -mno-tbm on a new line or
3. Can it be combined into a single line ie cflags-$(CONFIG_MPILEDRIVER) += -march=bdver2 -mno-tbm
4. or the hybrid: cflags-$(CONFIG_MPILEDRIVER) += -march=bdver2 $(call cc-option,-mno-tbm)

EDIT: Actually, I see it could very well be option 3.

% grep '+=' arch/x86/Makefile
KBUILD_CFLAGS += -mstack-protector-guard-reg=fs -mstack-protector-guard-symbol=__stack_chk_guard

f141161

from kernel_compiler_patch.

Oh, I was still compiling af5c6eb, let me start again with f141161 and ill let you know what happens

from kernel_compiler_patch.

@drfiemost - Thanks for the link. I agree with you in principal but since this patch only applies to 5.15 with at least gcc11 or at least clang12, I think we're good without it, no?

from kernel_compiler_patch.

Compiled using f141161 for Steamroller using Steamroller setting and it gave no warnings and booted fine

from kernel_compiler_patch.

f141161 made 5.15.2 build & boot with CONFIG_MPILEDRIVER=y on my FX8370 too. Thanks!

from kernel_compiler_patch.

There are a lot of objtool warnings while compiling, looks similar to #30

from kernel_compiler_patch.

I did hit #30 at that time too. But I think it's not the same. #30 is about the kernel not building at all with CONFIG_MPILEDRIVER=y.

This issue here is about the kernel building ok, but it won't run (won't even boot to the point I could get a dmesg via netconsole). I read the linked Gentoo Forums thread about CONFIG_STACK_VALIDATION and wanted to try with CONFIG_STACK_VALIDATION=n but I can't deselect it in my config, even when not using ORC unwinder.

Btw issue is the same on my Opteron 6386 SE box.

from kernel_compiler_patch.

Is 5.14.15 or 5.14.16 kernel CONFIG_MPILEDRIVER works for you?
gentoo-sources 5.15.0 was released after 5.14.14, so there is a chance you skipped them.

why I am asking.
Usually, I compile kernel with CONFIG_MSTEAMROLLER. Now, last working version is 5.14.14.
next kernels:
CONFIG_M*(yourcpuhere) compiles with objtool warnings and then does not boot;
CONFIG_GENERIC_CPU compiles without warnings, boot fine;
CONFIG_GENERIC_CPU[2-4] compiles without warnings, does not boot;

I am trying to figure out is this is related or I should create new issue.

from kernel_compiler_patch.

Is 5.14.15 or 5.14.16 kernel CONFIG_MPILEDRIVER works for you? gentoo-sources 5.15.0 was released after 5.14.14, so there is a chance you skipped them.

Yes, 5.14.16 works on my FX-8370 with CONFIG_MPILEDRIVER, also with CONFIG_MSTEAMROLLER on my A10-8750B. So it's probably a different issue.

But I'll double-check on both machines with 5.14.17 an report back here should I be wrong.

from kernel_compiler_patch.

From my understanding objtool isn't supposed to handle extended instructions like SIMD and whatever else, as those are not normally needed in the kernel code.
I wonder if it woulnd't be wiser to use -mtune instead of -march.

from kernel_compiler_patch.

So it is this patch causing it! I've been trying to boot 5.15.2 for the past couple days and have been getting a huge amount of objtool warnings and an unbootable kernel. I used my config from 5.14.14, did make oldconfig, and have always used CONFIG_MSTEAMROLLER.
The kernel panic message I get is jump_label: Fatal kernel bug, unexpected op at swap_writepage+0x17/0x70, if that's helpful at all

Just thought i'd add my experience here, thanks for the patch btw!

from kernel_compiler_patch.

@Pigpog - I am not sure what changed from 5.14.14 --> 5.15.2 that would cause this behavior. I am running 5.15.2 built with CONFIG_MZEN3 without any such errors. Something unique to steamroller and to piledriver (per @ernsteiswuerfel original report)? Is the steamroller able to use one of the newer x86-64 presets? What is the output of the following on it:

/lib/ld-linux-x86-64.so.2 --help | grep supported

from kernel_compiler_patch.

/lib/ld-linux-x86-64.so.2 --help | grep supported

x86-64-v2 (supported, searched)
x86_64 (AT_PLATFORM; supported, searched)
tls (supported, searched)
x86_64 (supported, searched)

// AMD A8-7200P

from kernel_compiler_patch.

Something unique to steamroller and to piledriver (per @ernsteiswuerfel original report)? Is the steamroller able to use one of the newer x86-64 presets? What is the output of the following on it:

Definitely a Steamroller/Piledriver issue I think. My Ryzen 9 5950X is fine with CONFIG_MZEN3 and my Athlon X2 3250e with CONFIG_MK8SSE3 on 5.15.x.

 $ /lib64/ld-linux-x86-64.so.2 --help | grep supported
  x86-64-v2 (supported, searched)
  x86_64 (AT_PLATFORM; supported, searched)
  tls (supported, searched)
  x86_64 (supported, searched)

//FX-8370

 $ /lib64/ld-linux-x86-64.so.2 --help | grep supported
  x86-64-v2 (supported, searched)
  x86_64 (AT_PLATFORM; supported, searched)
  tls (supported, searched)
  x86_64 (supported, searched)

//A10-8750B

from kernel_compiler_patch.

• Would you mind posting the output of gcc -c -Q -march=native --help=target | grep march from the FX-8370?
• Since all the affected hardware is generic-v2 compat, would one of you mind building 5.15.x with the generic-v2 target and test it on a machine that fails to boot with the specific target?

from kernel_compiler_patch.

$ gcc -c -Q -march=native --help=target | grep march
  -march=                     		bdver2
  Known valid arguments for -march= option:

Built with CONFIG_GENERIC_CPU2 kernel 5.15.2 boots fine on my FX8370!

from kernel_compiler_patch.

I might be off base with this but seems as though the body of evidence is pointing to the flag/compiler interacting with the 5.15 kernel in some way...

from kernel_compiler_patch.

... and to some subtle differences between bdver1, generic-v2 and bdver2.

Don't know wheter the compiler matters much as bdver2 kernels fail regardless of built with clang-13 or gcc-12. I can try older versions as well if this should be helpful.

from kernel_compiler_patch.

I honestly don't have a good plan to track this down.

from kernel_compiler_patch.

I just compiled 5.15.2 for bulldozer instead of steamroller and it booted just fine, and compiled without warnings. Here are the relevant bits of lscpu:

Architecture:            x86_64
  CPU op-mode(s):        32-bit, 64-bit
  Address sizes:         48 bits physical, 48 bits virtual
  Byte Order:            Little Endian
CPU(s):                  4
Vendor ID:               AuthenticAMD
  Model name:            AMD Athlon(tm) X4 860K Quad Core Processor
    CPU family:          21
    Model:               48
    Thread(s) per core:  2
    Core(s) per socket:  2
    Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx
                         16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb bpext ptsc cpb hw_pstate ssbd vmmcall fsgsb
                         ase bmi1 xsaveopt arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold overflow_recov

Perhaps I should try Piledriver optimizations for my Steamroller next? Let me know if there's any tests I should try, I have access to a few other architectures too (Coffee Lake, Sandy Bridge, Intel Atom, Caspian).

from kernel_compiler_patch.

@graysky2 it's the same issue as #55, it seems you've lost the -mno-tbm flag in the transition to 5.15

from kernel_compiler_patch.

@graysky2 it's the same issue as #55, it seems you've lost the -mno-tbm flag in the transition to 5.15

I can confirm. Adding -mno-tbm where it used to be made it compile without warnings and boots just fine. Thank you!

from kernel_compiler_patch.

OK, so patching 5.15.2 with f141161 and applying MBULLDOZER compiled fine. @Pigpog, you mind test building/booting?

from kernel_compiler_patch.

From the docs:

cc-option is used to check if $(CC) supports a given option, and if not supported to use an optional second option.

So it may be useful if there's any known compiler or compiler version which doesn't support the -mno-tbm flag.

from kernel_compiler_patch.