Messages in this thread | | | Date | Mon, 22 Aug 2022 19:43:18 +0800 | From | Qu Wenruo <> | Subject | Re: LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64 UEFI runtime) |
| |
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
| |