public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
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
Subject: Re: LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64 UEFI runtime)
Date: Mon, 22 Aug 2022 09:58:07 +0200	[thread overview]
Message-ID: <YwM3DwvPIGkfE4Tu@kroah.com> (raw)
In-Reply-To: <8aff5c17-d414-2412-7269-c9d15f574037@gmx.com>

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?  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 :)

good luck!

greg k-h

  reply	other threads:[~2022-08-22  7:58 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-22  1:15 LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64 UEFI runtime) Qu Wenruo
2022-08-22  6:25 ` Greg KH
2022-08-22  7:24   ` Qu Wenruo
2022-08-22  7:33     ` Greg KH
2022-08-22  7:49       ` Qu Wenruo
2022-08-22  7:58         ` Greg KH [this message]
2022-08-22  8:13           ` Qu Wenruo
2022-08-22  9:00             ` Greg KH
2022-08-22 11:43               ` Qu Wenruo
2022-08-22 11:58                 ` Willy Tarreau
2022-08-22 12:06                   ` Qu Wenruo
2022-08-22  8:04         ` Willy Tarreau
2022-08-22  8:19           ` Qu Wenruo
2022-08-22  8:30             ` Willy Tarreau
2022-08-22 11:07               ` Qu Wenruo
2022-08-22 11:42                 ` Greg KH
2022-08-22 11:53                 ` Willy Tarreau
2022-08-22 11:59                   ` Qu Wenruo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YwM3DwvPIGkfE4Tu@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-x86_64@vger.kernel.org \
    --cc=quwenruo.btrfs@gmx.com \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox