Subject: linux: Please build with CONFIG_KERNEL_GZIP=y instead of CONFIG_KERNEL_XZ=y on sh4

From: John Paul Adrian Glaubitz <[email-masked]>
Date: Fri, 25 Apr 2025 11:38:14 +0200

Source: linux
Version: 6.12.22-1
Severity: normal
User: [email-masked]
Usertags: sh4
X-Debbugs-Cc: [email-masked]

Hello,

src:linux currently fails to build from source on sh4 due to the kernel
image compression set to XZ (CONFIG_KERNEL_XZ=y). I tried setting the
compression to GZIP (CONFIG_KERNEL_GZIP=y) in debian/config/sh4/config
and disabling CONFIG_KERNEL_XZ with the following configuration:

##
## file: init/Kconfig
##
## choice: Kernel compression mode
#. Decompression is done by the bootloader, so we need to be
#. conservative here.
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_ZSTD is not set
## end choice
## choice: Compiler optimization level
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
## end choice

But for some reason that still resulted in CONFIG_KERNEL_XZ=y ending up
in the .config file of the sh7751lr kernel image.

However, I can enter the schroot after the failed build, edit the .config
files in /build/reproducible-path/linux-6.12.22/debian/build/build_sh4_none_sh7751r
and manually set CONFIG_KERNEL_GZIP=y and # CONFIG_KERNEL_XZ is not set which
makes the kernel build succeed when just running "make".

Thus, could you modify the configuration on sh4 such that the kernel is
compressed with GZIP instead of XZ (and ZSTD) by default so that the
kernel package builds again on sh4?

Using XZ doesn't make sense on sh4 with its small image sizes anyway.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

---

From: Ben Hutchings <[email-masked]>
Date: Fri, 02 May 2025 18:54:23 +0200

Control: tag -1 moreinfo

On Fri, 25 Apr 2025 11:38:14 +0200 John Paul Adrian Glaubitz <[email-masked]> wrote:
> image compression set to XZ (CONFIG_KERNEL_XZ=y).

You didn't say exactly why xz is a problem, but looking at the logs I
see xz sometimes failing with an out-of-memory error.

Are the sh4 builds running natively?

> I tried setting the

That change should work, and it does work for me.
 
> Using XZ doesn't make sense on sh4 with its small image sizes anyway.

Well, speaking of that, you have not yet reported back on whether my
fix-sh7785lcr branch works.  I just rebased this and uploaded fresh
packages to <https://people.debian.org/~benh/packages/linux-sh4/>.

If we apply this config change on top of that, the kernel image size for
sh7785lcr will again go over the 4 MiB limit.  So we would need to
either (1) trim the config further or (2) drop the sh7785lcr flavour.  I
do not intend to spend more time on (1) so this is really up to you (or
other sh4 porters) now.

Ben.

-- 
Ben Hutchings
It's easier to fight for one's principles than to live up to them.

---

From: John Paul Adrian Glaubitz <[email-masked]>
Date: Fri, 02 May 2025 19:59:02 +0200

Hi,

> see xz sometimes failing with an out-of-memory error.

Sorry, I thought I mentioned this.

> Are the sh4 builds running natively?

They're qemu-based except for tirpitz which is a native machine (actual hardware)

> do not intend to spend more time on (1) so this is really up to you (or

Yes, this is still on my TODO list and I have not forgotten it. I will eventually
come back to this. Currently, the main priority is maintaining the kernel upstream
as well as getting the SH backend in GCC converted to LRA which is coordinated with
people from the Dreamcast community.

Adrian

---

From: Ben Hutchings <[email-masked]>
Date: Fri, 02 May 2025 20:08:36 +0200

Control: tag -1 - moreinfo

> On Fri, 2025-05-02 at 18:54 +0200, Ben Hutchings wrote:
[...]
> people from the Dreamcast community.

Then I will drop that flavour, and you can re-add it when you are ready
to do so.

Ben.

-- 
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer

---

From: John Paul Adrian Glaubitz <[email-masked]>
Date: Fri, 02 May 2025 20:10:02 +0200

> Then I will drop that flavour, and you can re-add it when you are ready

Why do you need to drop it? I don't understand the reasoning behind it.

Does it hurt in any way when that flavor is being built?

Adrian

---

From: Ben Hutchings <[email-masked]>
Date: Fri, 02 May 2025 20:12:20 +0200

> Does it hurt in any way when that flavor is being built?

We know that it currently can't work.  So it is wasting the time of the
builders and of anyone who tries to use it.

Ben.

---

From: John Paul Adrian Glaubitz <[email-masked]>
Date: Fri, 02 May 2025 20:13:51 +0200

> builders and of anyone who tries to use it.

I'm maintaining those builders and I'm fine with that. It allows me to catch
regressions when looking at build logs.

Adrian

---

From: Ben Hutchings <[email-masked]>
Date: Fri, 02 May 2025 20:25:45 +0200

> regressions when looking at build logs.

There is nothing stopping you from doing your own kernel builds to test
whatever configuration and drivers you want.

Meanwhile in src:linux I think we only want to provide configurations
that are actually useful.

Ben.

---

From: Ben Hutchings <[email-masked]>
Date: Fri, 02 May 2025 20:55:45 +0200

[...]

By the way, this seems to be due to:

commit 8653c909922743bceb4800e5cc26087208c9e0e6
Author: Lasse Collin <[email-masked]>
Date:   Sun Jul 21 16:36:28 2024 +0300
 
    xz: use 128 MiB dictionary and force single-threaded mode

which causes xz to allocate 1346 MiB (!) at build time.

If you have the time, it might be worth trying to add an option to use a
smaller dictionary size again.

Ben.