On 2022/8/22 17:00, Greg KH wrote:
On Mon, Aug 22, 2022 at 04:13:03PM +0800, Qu Wenruo wrote:
On 2022/8/22 15:58, Greg KH wrote:
On Mon, Aug 22, 2022 at 03:49:51PM +0800, Qu Wenruo wrote:
On 2022/8/22 15:33, Greg KH wrote:
On Mon, Aug 22, 2022 at 03:24:53PM +0800, Qu Wenruo wrote:
On 2022/8/22 14:25, Greg KH wrote: > On Mon, Aug 22, 2022 at 09:15:59AM +0800, Qu Wenruo wrote: >> Hi, >> >> When backporting some btrfs specific patches to all LTS kernels, I found >> v4.14.290 kernel unable to boot as a KVM guest with edk2-ovmf >> (edk2-ovmf: 202205, qemu 7.0.0, libvirt 1:8.6.0). >> >> While all other LTS/stable branches (4.19.x, 5.4.x, 5.10.x, 5.15.x, >> 5.18.x, 5.19.x) can boot without a hipccup. >> >> I tried the following configs, but none of them can even provide an >> early output: >> >> - CONFIG_X86_VERBOSE_BOOTUP >> - CONFIG_EARLY_PRINTK >> - CONFIG_EARLY_PRINTK_EFI >> >> Is this a known bug or something new? > > Has this ever worked properly on this very old kernel tree? If so, can > you use 'git bisect' to find the offending commit?
Unfortunately the initial v4.14 from upstream can not even be compiled.
Really? Try using an older version of gcc and you should be fine. It did build properly back in 2017 when it was released :)
Yeah, I'm pretty sure my toolchain is too new for v4.14.0. But my distro only provides the latest and mostly upstream packages.
It may be a even worse disaster to find a way to rollback to older toolchains using my distro...
Also my hardware may not be well suited for older kernels either. (Zen 3 CPU used here)
In fact, I even find it hard just to locate a v4.14.x tag that can compile. After some bisection between v4.14.x tags, only v4.14.268 and newer tags can even be compiled using latest toolchain. (But still tons of warning, and tons of objdump warnings against insn_get_length()).
I'm not sure what's the normal practice for backports to such old branch.
Do you stable guys keep dedicated VMs loaded with older distro just for these old branches?
I don't, that's why those kernels can be built with newer versions of gcc.
Your distro should have a version of gcc-10 or gcc-9 that can be installed, right?
This may sounds like a meme, but I'm really using Archlinux for my VM and host, and it doesn't provide older GCC at all.
Archlinux does provide older gcc versions, that's what I use.
It still supports gcc11 in the main repo, and there is gcc10 in AUR as well as gcc9. Try those!
Thanks a lot, didn't even notice the gcc11 in official repos.
Tried to compile gcc10 from AUR, which failed to compile.
Anyway, thanks to the advice from Willy, I got the pre-built crosstool (gcc 7.5) set up, with some small tweaks like disabling CONFIG_RANDOMIZE_BASE to workaround the RELOCS failure, it at least compiles for v4.14.0.
Although there is still warning from test_gen_len:
Warning: ffffffff818158cc: 0f ff e9 ud0 %ecx,%ebp Warning: objdump says 3 bytes, but insn_get_length() says 2 Warning: arch/x86/tools/test_get_len found difference at <cpu_idle_poll>:ffffffff818159b0
And unfortunately v4.14 still fails to boot, even with GCC 7.5, which provides an almost perfect (except above wanrings) build.
I also tried to reduce the CPUid, from host-passthru to qemu64, and rebuild, no change (same test_get_len wanrings, same boot failure).
No clue at all now, would try older debian in a VM then.
If no change, a time period correct host maybe my next try...
Thanks, Qu
good luck!
greg k-h