Re: LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64 UEFI runtime)

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

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