* LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64 UEFI runtime) @ 2022-08-22 1:15 Qu Wenruo 2022-08-22 6:25 ` Greg KH 0 siblings, 1 reply; 18+ messages in thread From: Qu Wenruo @ 2022-08-22 1:15 UTC (permalink / raw) To: stable; +Cc: linux-btrfs, Linux Kernel Mailing List, linux-x86_64 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? Thanks, Qu ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64 UEFI runtime) 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 0 siblings, 1 reply; 18+ messages in thread From: Greg KH @ 2022-08-22 6:25 UTC (permalink / raw) To: Qu Wenruo; +Cc: stable, linux-btrfs, Linux Kernel Mailing List, linux-x86_64 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? thanks, greg k-h ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64 UEFI runtime) 2022-08-22 6:25 ` Greg KH @ 2022-08-22 7:24 ` Qu Wenruo 2022-08-22 7:33 ` Greg KH 0 siblings, 1 reply; 18+ messages in thread From: Qu Wenruo @ 2022-08-22 7:24 UTC (permalink / raw) To: Greg KH; +Cc: stable, linux-btrfs, Linux Kernel Mailing List, linux-x86_64 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. I'll try some more recent v4.14.x tags to see if I can get a working release to do the bisect. Thanks, Qu > > thanks, > > greg k-h ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64 UEFI runtime) 2022-08-22 7:24 ` Qu Wenruo @ 2022-08-22 7:33 ` Greg KH 2022-08-22 7:49 ` Qu Wenruo 0 siblings, 1 reply; 18+ messages in thread From: Greg KH @ 2022-08-22 7:33 UTC (permalink / raw) To: Qu Wenruo; +Cc: stable, linux-btrfs, Linux Kernel Mailing List, linux-x86_64 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 :) thanks, greg k-h ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64 UEFI runtime) 2022-08-22 7:33 ` Greg KH @ 2022-08-22 7:49 ` Qu Wenruo 2022-08-22 7:58 ` Greg KH 2022-08-22 8:04 ` Willy Tarreau 0 siblings, 2 replies; 18+ messages in thread From: Qu Wenruo @ 2022-08-22 7:49 UTC (permalink / raw) To: Greg KH; +Cc: stable, linux-btrfs, Linux Kernel Mailing List, linux-x86_64 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? If so, any recommendation on those kinda retro distro? Thanks, Qu > > thanks, > > greg k-h ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64 UEFI runtime) 2022-08-22 7:49 ` Qu Wenruo @ 2022-08-22 7:58 ` Greg KH 2022-08-22 8:13 ` Qu Wenruo 2022-08-22 8:04 ` Willy Tarreau 1 sibling, 1 reply; 18+ messages in thread From: Greg KH @ 2022-08-22 7:58 UTC (permalink / raw) To: Qu Wenruo; +Cc: stable, linux-btrfs, Linux Kernel Mailing List, linux-x86_64 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64 UEFI runtime) 2022-08-22 7:58 ` Greg KH @ 2022-08-22 8:13 ` Qu Wenruo 2022-08-22 9:00 ` Greg KH 0 siblings, 1 reply; 18+ messages in thread From: Qu Wenruo @ 2022-08-22 8:13 UTC (permalink / raw) To: Greg KH; +Cc: stable, linux-btrfs, Linux Kernel Mailing List, linux-x86_64 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. > 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64 UEFI runtime) 2022-08-22 8:13 ` Qu Wenruo @ 2022-08-22 9:00 ` Greg KH 2022-08-22 11:43 ` Qu Wenruo 0 siblings, 1 reply; 18+ messages in thread From: Greg KH @ 2022-08-22 9:00 UTC (permalink / raw) To: Qu Wenruo; +Cc: stable, linux-btrfs, Linux Kernel Mailing List, linux-x86_64 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! good luck! greg k-h ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64 UEFI runtime) 2022-08-22 9:00 ` Greg KH @ 2022-08-22 11:43 ` Qu Wenruo 2022-08-22 11:58 ` Willy Tarreau 0 siblings, 1 reply; 18+ messages in thread From: Qu Wenruo @ 2022-08-22 11:43 UTC (permalink / raw) To: Greg KH; +Cc: stable, linux-btrfs, Linux Kernel Mailing List, linux-x86_64 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64 UEFI runtime) 2022-08-22 11:43 ` Qu Wenruo @ 2022-08-22 11:58 ` Willy Tarreau 2022-08-22 12:06 ` Qu Wenruo 0 siblings, 1 reply; 18+ messages in thread From: Willy Tarreau @ 2022-08-22 11:58 UTC (permalink / raw) To: Qu Wenruo Cc: Greg KH, stable, linux-btrfs, Linux Kernel Mailing List, linux-x86_64 On Mon, Aug 22, 2022 at 07:43:18PM +0800, Qu Wenruo wrote: > 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 Strange, sounds like a binutils issue though I could be wrong. > 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. I suggest that instead of switching distros you should rather first try 4.14.0 to verify if there was a regression affecting your system. And if so, then a bisect will certainly be welcome. If it still does not work, then maybe a different distro could help, though I doubt it. Willy ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64 UEFI runtime) 2022-08-22 11:58 ` Willy Tarreau @ 2022-08-22 12:06 ` Qu Wenruo 0 siblings, 0 replies; 18+ messages in thread From: Qu Wenruo @ 2022-08-22 12:06 UTC (permalink / raw) To: Willy Tarreau Cc: Greg KH, stable, linux-btrfs, Linux Kernel Mailing List, linux-x86_64 On 2022/8/22 19:58, Willy Tarreau wrote: > On Mon, Aug 22, 2022 at 07:43:18PM +0800, Qu Wenruo wrote: >> 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 > > Strange, sounds like a binutils issue though I could be wrong. I'm using CROSS_COMPILE= option, which should cover the objdump from the prebuilt "x86_64-linux-objdump" from that precompiled 7.5 crosstool. > >> 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. > > I suggest that instead of switching distros you should rather first > try 4.14.0 to verify if there was a regression affecting your system. Already tried, the v4.14 above really means v4.14.0 (aka v4.14 tag directly from upstream, not from stable). And the latest v4.14.290 can not boot neither, even rebuilt using that toolchain. > And if so, then a bisect will certainly be welcome. If it still does > not work, then maybe a different distro could help, though I doubt it. Will try debian for now, or even try some older hardware if I could find... Thanks, Qu > > Willy ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64 UEFI runtime) 2022-08-22 7:49 ` Qu Wenruo 2022-08-22 7:58 ` Greg KH @ 2022-08-22 8:04 ` Willy Tarreau 2022-08-22 8:19 ` Qu Wenruo 1 sibling, 1 reply; 18+ messages in thread From: Willy Tarreau @ 2022-08-22 8:04 UTC (permalink / raw) To: Qu Wenruo Cc: Greg KH, stable, linux-btrfs, Linux Kernel Mailing List, linux-x86_64 On Mon, Aug 22, 2022 at 03:49:51PM +0800, Qu Wenruo wrote: > 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. Then there's something odd in your use case. Old kernels are aimed at those who need to have systems on which nothing changes. It's particularly strange to be stuck in the past for the kernel but to continually upgrade userland. Most often it's the opposite that's seen. Regardless, if you need an older compiler, just use these ones: https://mirrors.edge.kernel.org/pub/tools/crosstool/ They go back to 4.9.4 for x86, you'll surely find the right one for your usage. I've long used 4.7.4 for kernels up to 4.9 and 6.5 for 4.19 and above, so something within that area will surely match your needs. > It may be a even worse disaster to find a way to rollback to older > toolchains using my distro... No, using a prebuilt toolchain like those above is quite trivial and it will avoid messing up with your local packages. That's the best solution I can recommend. Willy ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64 UEFI runtime) 2022-08-22 8:04 ` Willy Tarreau @ 2022-08-22 8:19 ` Qu Wenruo 2022-08-22 8:30 ` Willy Tarreau 0 siblings, 1 reply; 18+ messages in thread From: Qu Wenruo @ 2022-08-22 8:19 UTC (permalink / raw) To: Willy Tarreau Cc: Greg KH, stable, linux-btrfs, Linux Kernel Mailing List, linux-x86_64 On 2022/8/22 16:04, Willy Tarreau wrote: > On Mon, Aug 22, 2022 at 03:49:51PM +0800, Qu Wenruo wrote: >> 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. > > Then there's something odd in your use case. Old kernels are aimed at > those who need to have systems on which nothing changes. It's particularly > strange to be stuck in the past for the kernel but to continually upgrade > userland. Most often it's the opposite that's seen. Yep, that's my bad, just too lazy to get a time-period correct distro, or learn other package management tools from other distros. > > Regardless, if you need an older compiler, just use these ones: > > https://mirrors.edge.kernel.org/pub/tools/crosstool/ > > They go back to 4.9.4 for x86, you'll surely find the right one for your > usage. I've long used 4.7.4 for kernels up to 4.9 and 6.5 for 4.19 and > above, so something within that area will surely match your needs. BTW, it would be way more awesome if the page can provide some hint on the initial release date of the compilers. It would help a lot of choose the toolchain then. > >> It may be a even worse disaster to find a way to rollback to older >> toolchains using my distro... > > No, using a prebuilt toolchain like those above is quite trivial and > it will avoid messing up with your local packages. That's the best > solution I can recommend. Thanks for all the info, it really helps a lot, Qu > > Willy ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64 UEFI runtime) 2022-08-22 8:19 ` Qu Wenruo @ 2022-08-22 8:30 ` Willy Tarreau 2022-08-22 11:07 ` Qu Wenruo 0 siblings, 1 reply; 18+ messages in thread From: Willy Tarreau @ 2022-08-22 8:30 UTC (permalink / raw) To: Qu Wenruo Cc: Greg KH, stable, linux-btrfs, Linux Kernel Mailing List, linux-x86_64 On Mon, Aug 22, 2022 at 04:19:49PM +0800, Qu Wenruo wrote: > > Regardless, if you need an older compiler, just use these ones: > > > > https://mirrors.edge.kernel.org/pub/tools/crosstool/ > > > > They go back to 4.9.4 for x86, you'll surely find the right one for your > > usage. I've long used 4.7.4 for kernels up to 4.9 and 6.5 for 4.19 and > > above, so something within that area will surely match your needs. > > BTW, it would be way more awesome if the page can provide some hint on > the initial release date of the compilers. > > It would help a lot of choose the toolchain then. It wouldn't help, if you look closely, you'll notice that in the "other releases" section you have the most recent version of each of them. That does not preclude the existence of the branch earlier. For example gcc-9 was released in 2019 and 9.5 was emitted 3 years later. That's quite an amplitude that doesn't help. Willy ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64 UEFI runtime) 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 0 siblings, 2 replies; 18+ messages in thread From: Qu Wenruo @ 2022-08-22 11:07 UTC (permalink / raw) To: Willy Tarreau Cc: Greg KH, stable, linux-btrfs, Linux Kernel Mailing List, linux-x86_64 On 2022/8/22 16:30, Willy Tarreau wrote: > On Mon, Aug 22, 2022 at 04:19:49PM +0800, Qu Wenruo wrote: >>> Regardless, if you need an older compiler, just use these ones: >>> >>> https://mirrors.edge.kernel.org/pub/tools/crosstool/ >>> >>> They go back to 4.9.4 for x86, you'll surely find the right one for your >>> usage. I've long used 4.7.4 for kernels up to 4.9 and 6.5 for 4.19 and >>> above, so something within that area will surely match your needs. >> >> BTW, it would be way more awesome if the page can provide some hint on >> the initial release date of the compilers. >> >> It would help a lot of choose the toolchain then. > > It wouldn't help, if you look closely, you'll notice that in the "other > releases" section you have the most recent version of each of them. That > does not preclude the existence of the branch earlier. For example gcc-9 > was released in 2019 and 9.5 was emitted 3 years later. That's quite an > amplitude that doesn't help. Maybe I'm totally wrong, but if GCC10.1 is released May 2020, and even 10.4 is released 2022, then shouldn't we expect the kernel releases around 2020 can be compiled for all GCC 10.x releases? Thus the initial release date should be a good enough hint for most cases. If go this method, for v4.14 I guess I should go gcc 7.x, as gcc 7.1 is released May 2017, even the latest 7.5 is released 2019. Or is my uneducated guess completely wrong? Thanks, Qu > > Willy ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64 UEFI runtime) 2022-08-22 11:07 ` Qu Wenruo @ 2022-08-22 11:42 ` Greg KH 2022-08-22 11:53 ` Willy Tarreau 1 sibling, 0 replies; 18+ messages in thread From: Greg KH @ 2022-08-22 11:42 UTC (permalink / raw) To: Qu Wenruo Cc: Willy Tarreau, stable, linux-btrfs, Linux Kernel Mailing List, linux-x86_64 On Mon, Aug 22, 2022 at 07:07:19PM +0800, Qu Wenruo wrote: > > > On 2022/8/22 16:30, Willy Tarreau wrote: > > On Mon, Aug 22, 2022 at 04:19:49PM +0800, Qu Wenruo wrote: > > > > Regardless, if you need an older compiler, just use these ones: > > > > > > > > https://mirrors.edge.kernel.org/pub/tools/crosstool/ > > > > > > > > They go back to 4.9.4 for x86, you'll surely find the right one for your > > > > usage. I've long used 4.7.4 for kernels up to 4.9 and 6.5 for 4.19 and > > > > above, so something within that area will surely match your needs. > > > > > > BTW, it would be way more awesome if the page can provide some hint on > > > the initial release date of the compilers. > > > > > > It would help a lot of choose the toolchain then. > > > > It wouldn't help, if you look closely, you'll notice that in the "other > > releases" section you have the most recent version of each of them. That > > does not preclude the existence of the branch earlier. For example gcc-9 > > was released in 2019 and 9.5 was emitted 3 years later. That's quite an > > amplitude that doesn't help. > > Maybe I'm totally wrong, but if GCC10.1 is released May 2020, and even > 10.4 is released 2022, then shouldn't we expect the kernel releases > around 2020 can be compiled for all GCC 10.x releases? > > Thus the initial release date should be a good enough hint for most cases. > > If go this method, for v4.14 I guess I should go gcc 7.x, as gcc 7.1 is > released May 2017, even the latest 7.5 is released 2019. > > Or is my uneducated guess completely wrong? Try it and see! ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64 UEFI runtime) 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 1 sibling, 1 reply; 18+ messages in thread From: Willy Tarreau @ 2022-08-22 11:53 UTC (permalink / raw) To: Qu Wenruo Cc: Greg KH, stable, linux-btrfs, Linux Kernel Mailing List, linux-x86_64 On Mon, Aug 22, 2022 at 07:07:19PM +0800, Qu Wenruo wrote: > > > On 2022/8/22 16:30, Willy Tarreau wrote: > > On Mon, Aug 22, 2022 at 04:19:49PM +0800, Qu Wenruo wrote: > > > > Regardless, if you need an older compiler, just use these ones: > > > > > > > > https://mirrors.edge.kernel.org/pub/tools/crosstool/ > > > > > > > > They go back to 4.9.4 for x86, you'll surely find the right one for your > > > > usage. I've long used 4.7.4 for kernels up to 4.9 and 6.5 for 4.19 and > > > > above, so something within that area will surely match your needs. > > > > > > BTW, it would be way more awesome if the page can provide some hint on > > > the initial release date of the compilers. > > > > > > It would help a lot of choose the toolchain then. > > > > It wouldn't help, if you look closely, you'll notice that in the "other > > releases" section you have the most recent version of each of them. That > > does not preclude the existence of the branch earlier. For example gcc-9 > > was released in 2019 and 9.5 was emitted 3 years later. That's quite an > > amplitude that doesn't help. > > Maybe I'm totally wrong, but if GCC10.1 is released May 2020, and even > 10.4 is released 2022, then shouldn't we expect the kernel releases > around 2020 can be compiled for all GCC 10.x releases? > > Thus the initial release date should be a good enough hint for most cases. If you speak about initial release, yes that should generally be a valid assumption. > If go this method, for v4.14 I guess I should go gcc 7.x, as gcc 7.1 is > released May 2017, even the latest 7.5 is released 2019. Then it should definitely work. But I think you're spending way too much time comparing dates and discussing on the subject. By the time it took to check these dates, you could already have downloaded one such compiler and built a kernel to verify it did build correctly ;-) Willy ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64 UEFI runtime) 2022-08-22 11:53 ` Willy Tarreau @ 2022-08-22 11:59 ` Qu Wenruo 0 siblings, 0 replies; 18+ messages in thread From: Qu Wenruo @ 2022-08-22 11:59 UTC (permalink / raw) To: Willy Tarreau Cc: Greg KH, stable, linux-btrfs, Linux Kernel Mailing List, linux-x86_64 On 2022/8/22 19:53, Willy Tarreau wrote: > On Mon, Aug 22, 2022 at 07:07:19PM +0800, Qu Wenruo wrote: >> >> >> On 2022/8/22 16:30, Willy Tarreau wrote: >>> On Mon, Aug 22, 2022 at 04:19:49PM +0800, Qu Wenruo wrote: >>>>> Regardless, if you need an older compiler, just use these ones: >>>>> >>>>> https://mirrors.edge.kernel.org/pub/tools/crosstool/ >>>>> >>>>> They go back to 4.9.4 for x86, you'll surely find the right one for your >>>>> usage. I've long used 4.7.4 for kernels up to 4.9 and 6.5 for 4.19 and >>>>> above, so something within that area will surely match your needs. >>>> >>>> BTW, it would be way more awesome if the page can provide some hint on >>>> the initial release date of the compilers. >>>> >>>> It would help a lot of choose the toolchain then. >>> >>> It wouldn't help, if you look closely, you'll notice that in the "other >>> releases" section you have the most recent version of each of them. That >>> does not preclude the existence of the branch earlier. For example gcc-9 >>> was released in 2019 and 9.5 was emitted 3 years later. That's quite an >>> amplitude that doesn't help. >> >> Maybe I'm totally wrong, but if GCC10.1 is released May 2020, and even >> 10.4 is released 2022, then shouldn't we expect the kernel releases >> around 2020 can be compiled for all GCC 10.x releases? >> >> Thus the initial release date should be a good enough hint for most cases. > > If you speak about initial release, yes that should generally be a valid > assumption. > >> If go this method, for v4.14 I guess I should go gcc 7.x, as gcc 7.1 is >> released May 2017, even the latest 7.5 is released 2019. > > Then it should definitely work. But I think you're spending way too much > time comparing dates and discussing on the subject. By the time it took > to check these dates, you could already have downloaded one such compiler > and built a kernel to verify it did build correctly ;-) That's completely true. Except the fact that, even with time period correct tool chain (gcc 7.5), the compiled v4.14.x kernel (tried both 4.14.0 and latest 4.14.290), neither can boot nor cause any early boot message to pop up. :( Anyway, thank you very much for the toolchain part, it would definitely help for my future adventure related to stable kernels (looking at tons of v4.12 related branches with sad face). Thanks, Qu > > Willy ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2022-08-22 12:07 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.