Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <acc6051b-748f-4f06-63b3-919eb831217c@gmx.com>
Date:   Mon, 22 Aug 2022 16:13:03 +0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.12.0
Subject: Re: LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64
 UEFI runtime)
Content-Language: en-US
To:     Greg KH <gregkh@linuxfoundation.org>
Cc:     stable <stable@vger.kernel.org>,
        "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        linux-x86_64@vger.kernel.org
References: <2d6012e8-805d-4225-80ed-d317c28f1899@gmx.com>
 <YwMhXX6OhROLZ/LR@kroah.com> <1ed5a33a-b667-0e8e-e010-b4365f3713d6@gmx.com>
 <YwMxRAfrrsPE6sNI@kroah.com> <8aff5c17-d414-2412-7269-c9d15f574037@gmx.com>
 <YwM3DwvPIGkfE4Tu@kroah.com>
From:   Qu Wenruo <quwenruo.btrfs@gmx.com>
In-Reply-To: <YwM3DwvPIGkfE4Tu@kroah.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Precedence: bulk


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 compile=
d.
>>>
>>> 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 distr=
o
>> 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 comp=
ile.
>> After some bisection between v4.14.x tags, only v4.14.268 and newer tag=
s
>> 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 branc=
h.
>>
>> 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.

>  Or maybe use the gcc versions on kernel.org that only
> work for kernel builds?
>
>> If so, any recommendation on those kinda retro distro?
>
> Try installing an old version of Debian, or better yet, use a distro
> that provides old versions of gcc :)

I guess that's the only way to go.

Thanks for all the advice,
Qu

>
> good luck!
>
> greg k-h