XPost: linux.debian.ports.superh, linux.debian.kernel

Source: linux
Version: 6.12.22-1
Severity: normal
User: debian-superh@lists.debian.org
Usertags: sh4
X-Debbugs-Cc: debian-superh@lists.debian.org

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.kernel

Control: tag -1 moreinfo

On Fri, 25 Apr 2025 11:38:14 +0200 John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:

Source: linux
Version: 6.12.22-1
Severity: normal
User: debian-superh@lists.debian.org
Usertags: sh4
X-Debbugs-Cc: debian-superh@lists.debian.org

Hello,

src:linux currently fails to build from source on sh4 due to the kernel
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
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.

That change should work, and it does work for me.

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.

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.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAmgU+L8ACgkQ57/I7JWG EQk/UhAAx8rgFJ21lWrs26UBJGcd1gX8QPun4nCuqrMx+nup/zv9XNJd7lVpvh1f Ro4fx64sT28i3lXiqO4l8qb/LqicmqvaorO4PZNcBVtLUoFNVqpEByaagnMU1lPN obr+my8qDSExXpAG/DmF9mFNxP+SzzUv66ggBWhFJPHU+0PHgM0hh/dx5WUxmNpX RERXrmKZ8vnQJzVGeZQ+aPzBsEd1vtBERC8izFrKmL8LDx+Pw8Uply2G/qRz27lI tzDYB0FxS0BWZxT4wOv2K3P7oClHmfNSy6QBoNX2wS5XyC87OAxJz3SaIkA0pX4F Tx6aAPWPyHH4z/G/0pp/6ByHnK6rLl1UJaySyp0cf58ev6zFejtWaTm2VSnW6g+I KzLaCQ8wkZAQRa253B8j17fe86doLsKws7RW3Tim5fpaip+r8Jo0xkkuQ4w3hn8y 88Fx4pU7vVsEiddudkAiuX4ko8GJVyv6tgcd4MtZp4YAPdhs72AnJ981vR6di3U5 Syy8un0Kbkmu8qtbWp1ti45bax3Uq6s1r4jC3hN3lSO8/z2niz/Qu1q1/JmQHXc8 mtG5WezyU3r7Ei3eIpXhvNLPMwhrbz1y/S8HXYkobPIHNilE3EKrq0xaQMdwIoI2 wO7Vfi3VkmbdtQIRKpeLB/GtnI7E+jUQxJOiRL6jBLs2T5kLgSk=
=1uGz
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.kernel

Hi,

On Fri, 2025-05-02 at 18:54 +0200, Ben Hutchings wrote:

src:linux currently fails to build from source on sh4 due to the kernel 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.

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)

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.

That change should work, and it does work for me.

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.

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.

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

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.kernel

Control: tag -1 - moreinfo

On Fri, 2025-05-02 at 19:59 +0200, John Paul Adrian Glaubitz wrote:

Hi,

On Fri, 2025-05-02 at 18:54 +0200, Ben Hutchings wrote:

[...]

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.

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.

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

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAmgVCiQACgkQ57/I7JWG EQnqBw/+P45+4558JFs14z9xI35NQy2R6F+N4S8MP3/e39RFr2pohmv4kvO6HY6d l+01G/bzIwBmYQN8ieusfCmSS42doUqKM9Rb3Dt7A3D0dndo0sF+W48gyeO/iPfO lNT5Rqd4VUQxsHxK8Nbq6PjSZbix2lIZpWgbv88srkjGUkNkXvRuefRAnerIAHwL B7lPmwhs/GpOmR7ULxsFFHTnhXzVpjyr8KKkRIqUmzD8W7YxGKA1xkoxsvIZR0cz HU/TD+ChaPe4u9Gj1QkwnMKxQ1sbxkEiKyyU1QzvAV/dhNeOzdiaZNV5J+7AW7bj xHQ3VrWogGl74+yPNL8Dj3Z81wk3syBMYxy+mmd89eJkJcHD8Tjtxb3xkP9k+OMc hBnqFsrFxzNb1drywR1zFihZglyq/weQ3fK4r1iY4HtU94cbfOKHQ0559aMvSqxr FyFjesnH1zR3G+iM99RNApNVJE4PQlQC5hc5e/EnaDP/7QtmUwA1KCuPYKgC/w8N BtNChBpAb0Q1W2cYsfqKw0WEcgwes0lHOuCv4IqaYQVLs0DqhcDo21V2QGc9uck8 +n5a3xC3U3l+9/jNTPRj1EyYKtKa6vwjAmcK0Fg7C2x37C8nwNwV0/Fh5239sgiU ACc5nI+37vqewTQgxbVqwVY9FTpxi3MgpE5u5hmAKmeqEY1s2O0=
=flc9
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.kernel

On Fri, 2025-05-02 at 20:13 +0200, John Paul Adrian Glaubitz wrote:

On Fri, 2025-05-02 at 20:12 +0200, Ben Hutchings wrote:

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?

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.

I'm maintaining those builders and I'm fine with that. It allows me to catch 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.

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

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAmgVDikACgkQ57/I7JWG EQnTFg/9HNCwUlFjpfSj6sWnpZ22ioiBMx0VBmjvMAbxt53UZgNCT/BHagbRIuSi ft9Zvleia1AP+QXFIxLk22Es93nUYIApo+Nlu3Df9+F/50P3jBKkokqUf4r5wlw2 zgPhQqwrmrpELKA5mO3yVyzLV/xcpfs0ZIZQG6RZPrIkAMVuuWfhbG0lOb0/mzYR TE25RMpkYoiauAB4+P/RGVSNq8ob9MXF3r+s+8p3ziYoih5KwyUhGfLPvP71qrBb 7aF1//DbZbgXHlYxlz9OeFVZoM5r3KsroVNdMQho2X5uvRd0bc3/JNC8gqmzERgc tkZ4mHO7RP928+QAHRplX1+cuJfi5cCbRg1pwDyv75ZEe5gE/6qGqZEwRCGFaTvS qQ0RDhrtVpHD1o3tFxgPm3V6Kzfo1KoEndAR44a6a8yMB4iym50cM7aC3H0o/vMl Iow7n1v2qhi4kvHjLKuUTfyN7TqcZe9mRVVz6Nw4TyIZabCtx6gmH81H+OvNQa9h HbIB0mw8exdgL3r8P396hxaWQgOxlyTJLJ0VZ4jIRjocwy7o9r9bJq31nsIkPTGx ZK9N0eM38AAG1IuqXIj3q0qwhvKMMxl2vlnovlJJvqNFAWGvVhOyXL8bvAdGA2zZ grV/wou+BTaWIj2utdFj2Ux/Lrzw9tpd5VyHLPVZMPx1v6H1uNk=
=gpza
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.kernel

On Fri, 2025-05-02 at 18:54 +0200, Ben Hutchings wrote:

Control: tag -1 moreinfo

On Fri, 25 Apr 2025 11:38:14 +0200 John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:

Source: linux
Version: 6.12.22-1
Severity: normal
User: debian-superh@lists.debian.org
Usertags: sh4
X-Debbugs-Cc: debian-superh@lists.debian.org

Hello,

src:linux currently fails to build from source on sh4 due to the kernel 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.

[...]

By the way, this seems to be due to:

commit 8653c909922743bceb4800e5cc26087208c9e0e6
Author: Lasse Collin <lasse.collin@tukaani.org>
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.

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

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAmgVFTEACgkQ57/I7JWG EQmtSA//WOCByQZHz/USxrj47XmQD7RjL7hyNcKtJNw4FZqJPKr/t+8YjUJ+0HoE mJc0QmmAl8Uwo7xV+potil5hc8bcY14uBQopXRRFz4dgESVfO0pDL52O4INpmUUy UdRrif2w0nSPnMUhuYg3JXns7CX3osJX2N711MEbGmjWmvVx3q8Zo+FUmWdttcoY GOwCb9Jv4dSkvB/E5h1QlePF4Pa+ZwqMh/s77BwujQ5KspcEKvR708WLP2FKccjO iWikchP2aG48k8nQTThaFpwrQe1NjQntCe8aZh4LSWX9X/nZb0G2WsRTGEB5mAK1 vsSOyTaZN1Y2Bf8kD/JIflWXuxfWi6VJhI54jEnMwmbNz2llAHf++og5OJLS6aRO 8SgW8kuMg/PaLBq6/K/BKBtVE1tAgOyT9L9RtQtqbzfzF/lsubOKmTaqOsFB+IEQ kDFTxlk1FGwUeJNzpBINP1T3fGUWxsYo91A7zKrmY0R0P8oSCcpoFusriP8d3yU5 Bu+Yl1mGx7P9kJULZB8XvwxOXsJ1/xr1GNmgoraWBrM6Efvg27lGFbJp2eO6MMn8 TG+I51iNOcf6nYylEoHT+mQN4FveZrWKD+B7Daj7OCipWhvt3ejHnuak46pB3bB3 i/P7KvAu0RHg2xGWJuotLERmOZFhvgyWoaoEIEmKIVXK98mZHUU=
=0axD
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)