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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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!
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
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
linux-stable-mirror@lists.linaro.org
-
Greg KH -
Qu Wenruo -
Willy Tarreau