x86_64 kernels fail to boot after D140931 #1800
Comments
|
Thanks for the report. Are you able to run a bisection against LLVM to find which commit may be the culprit? |
nickdesaulniers
added
the
more info needed
|
@nickdesaulniers I am afraid, I cannot afford too much time for that at the moment. If it is a more widespread issue, I am sure it will pop up sooner or later on some bots. I'll re-visit this with a future ToT-LLVM-17 snapshot and let you know if it had been fixed by then. |
|
I'll see if I can reproduce this in QEMU at some point today. |
|
I can reproduce this with just defconfig and mainline with current LLVM main, I am about to bisect once I find a good point. I ran into a separate QEMU main regression that impacted my ability to use my full distribution QEMU wrapper to boot my own kernels and I never thought to try |
|
My bisect landed on commit ee5585ed09af ("Recommit "Improve and enable folding of conditional branches with tail calls." (2nd Try)"). I will see if I can investigate more tomorrow, unless somebody else beats me to it. |
nathanchance
added
[BUG] llvm (main)
nathanchance
changed the title
|
Okay, this ultimately appears to have the same root cause and fix as #1774. As far as I understand it, the LLVM patch causes the problematic sequence of instructions to be emitted that caused #1774, even at In other words, if I build a kernel using a toolchain that contains llvm/llvm-project@ee5585e and I pull the current I will ping that thread to see if these patches can be merged into mainline ahead of 6.3 and inquire about a backport to 6.1, as the series appears to require some changes from the call depth tracking series that was merged in 6.2. |
nathanchance
added
[BUG] linux
This change get us back onto llvm-16 by default as it seemsthat currently, qemu VMs are failing to boot when the kernel is built with llvm 17, it is very likely related to ClangBuiltLinux/linux#1800 . Because of the layout of LLVM's apt repo, unless the version is the latest they distribute, the repository distro need to use the version number as suffix. Signed-off-by: Manu Bretelle <[email protected]>
This change get us back onto llvm-16 by default as it seemsthat currently, qemu VMs are failing to boot when the kernel is built with llvm 17, it is very likely related to ClangBuiltLinux/linux#1800 . Because of the layout of LLVM's apt repo, unless the version is the latest they distribute, the repository distro need to use the version number as suffix. Signed-off-by: Manu Bretelle <[email protected]>
|
Closing this in favor of #1774, which I have renamed to more accurately describe the issue. |
nathanchance
added
duplicate
…atic calls on x86 A recent change in LLVM causes these to be generated even at -O2 so apply Peter's series that fixes this in -tip. I have requested that this series be applied to mainline so that it can be backported quicker, we will see if that request is honored. Link: ClangBuiltLinux/linux#1774 Link: ClangBuiltLinux/linux#1800 Signed-off-by: Nathan Chancellor <[email protected]>
Uh oh!
There was an error while loading. Please reload this page.
I've been on the distribution provided Clang-15.0.7 for a while and tried out LLVM/Clang-17 (7bff37783f72ed99e4cdd0fd7dad1bf1f119f793) today, I've noticed that my 6.1.10 Kernel compiled and booted fine with Clang-15 but now fails to boot with Clang-17 and the same flags/patches used. It hangs right when Grub tries to load the Kernel image. CPU: Intel Haswell-EP, 64-bit.
More details on the patches used, as always, in my public repo.
config.txt
While skimming through other issues, I've found #1774, but while the symptoms were the same, I cannot tell if they are related. As I compile my Kernel with
-O3, and the patch series adressed issues with-Os, it seems to be something different to me.The text was updated successfully, but these errors were encountered: