Your message dated Wed, 03 May 2023 07:18:52 +0000
with message-id <[email protected]>
and subject line Bug#1033301: fixed in dwarves 1.24-4.1
has caused the Debian Bug report #1033301,
regarding pahole: BTF deduplication issues causing arm64 kernel size increase
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1033301: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033301
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Source: linux
Version: 6.1.15-1
Severity: important
Tags: upstream
X-Debbugs-Cc: [email protected]
Control: affects -1 + u-boot-rpi
Hi,
Following the upgrade of the kernel from 6.1.12-1 to 6.1.15-1 on a
Raspberry Pi 3 Model B Plus, u-boot (from the u-boot-rpi package) failed
to boot with:
| 40175552 bytes read in 1695 ms (23 MiB/s)
| 43794863 bytes read in 1817 ms (23 MiB/s)
| Moving Image from 0x80000 to 0x200000, end=2990000
| ERROR: RD image overlaps OS image (OS=0x200000..0x2990000)
I tracked the issue to a significant increase of the kernel size between
version 6.1.12-1 and 6.15-1:
| 31492 /boot/vmlinuz-6.1.0-5-arm64
| 39236 /boot/vmlinuz-6.1.0-6-arm64
This is more than the 36MB that is allowed by u-boot with the default
load addresses. A workaround is to shift the load addresses at the
u-boot level as in the attached patch.
I have tracked issue on the upstream kernel side to the following commit
on the stable tree:
| commit 3e3e4d234d46e48480a7c7c35399fa811182e8ef
| Author: Masahiro Yamada <[email protected]>
| Date: Thu Oct 13 08:35:00 2022 +0900
|
| arm64: remove special treatment for the link order of head.o
|
| commit 994b7ac1697b4581b7726d2ac64321e3c840229b upstream.
|
| In the previous discussion (see the Link tag), Ard pointed out that
| arm/arm64/kernel/head.o does not need any special treatment - the only
| piece that must appear right at the start of the binary image is the
| image header which is emitted into .head.text.
|
| The linker script does the right thing to do. The build system does
| not need to manipulate the link order of head.o.
|
| Link:
https://lore.kernel.org/lkml/CAMj1kXH77Ja8bSsq2Qj8Ck9iSZKw=1F8Uy-uAWGVDm4-CG=e...@mail.gmail.com/
| Suggested-by: Ard Biesheuvel <[email protected]>
| Signed-off-by: Masahiro Yamada <[email protected]>
| Reviewed-by: Nicolas Schier <[email protected]>
| Link:
https://lore.kernel.org/r/[email protected]
| Signed-off-by: Will Deacon <[email protected]>
| Signed-off-by: Tom Saeger <[email protected]>
| Signed-off-by: Greg Kroah-Hartman <[email protected]>
The problem is still reproducible on Linus' master.
I am reporting the bug to the linux package as I believed there is no
real reason for such an increase in the kernel size. In case I missed
something and this is actually wanted, the bug can be reassigned to the
u-boot package.
Regards
Aurelien
--- u-boot-2023.01+dfsg.orig/include/configs/rpi.h
+++ u-boot-2023.01+dfsg/include/configs/rpi.h
@@ -95,32 +95,32 @@
* text_offset bytes (specified in the header of the Image) into a 2MB
* boundary. The 'booti' command relocates the image if necessary. Linux uses
* a default text_offset of 0x80000. In summary, loading at 0x80000
- * satisfies all these constraints and reserving memory up to 0x02400000
- * permits fairly large (roughly 36M) kernels.
+ * satisfies all these constraints and reserving memory up to 0x02a00000
+ * permits fairly large (roughly 42M) kernels.
*
* scriptaddr and pxefile_addr_r can be pretty much anywhere that doesn't
* conflict with something else. Reserving 1M for each of them at
- * 0x02400000-0x02500000 and 0x02500000-0x02600000 should be plenty.
+ * 0x02a00000-0x02b00000 and 0x02c00000-0x02d00000 should be plenty.
*
* On ARM, both the DTB and any possible initrd must be loaded such that they
* fit inside the lowmem mapping in Linux. In practice, this usually means not
* more than ~700M away from the start of the kernel image but this number can
* be larger OR smaller depending on e.g. the 'vmalloc=xxxM' command line
* parameter given to the kernel. So reserving memory from low to high
- * satisfies this constraint again. Reserving 1M at 0x02600000-0x02700000 for
- * the DTB leaves rest of the free RAM to the initrd starting at 0x02700000.
+ * satisfies this constraint again. Reserving 1M at 0x02c00000-0x02d00000 for
+ * the DTB leaves rest of the free RAM to the initrd starting at 0x02d00000.
* Even with the smallest possible CPU-GPU memory split of the CPU getting
- * only 64M, the remaining 25M starting at 0x02700000 should allow quite
+ * only 64M, the remaining 19M starting at 0x02d00000 should allow quite
* large initrds before they start colliding with U-Boot.
*/
#define ENV_MEM_LAYOUT_SETTINGS \
"fdt_high=" FDT_HIGH "\0" \
"initrd_high=" INITRD_HIGH "\0" \
"kernel_addr_r=0x00080000\0" \
- "scriptaddr=0x02400000\0" \
- "pxefile_addr_r=0x02500000\0" \
- "fdt_addr_r=0x02600000\0" \
- "ramdisk_addr_r=0x02700000\0"
+ "scriptaddr=0x02a00000\0" \
+ "pxefile_addr_r=0x02b00000\0" \
+ "fdt_addr_r=0x02c00000\0" \
+ "ramdisk_addr_r=0x02d00000\0"
#if CONFIG_IS_ENABLED(CMD_MMC)
#define BOOT_TARGET_MMC(func) \
--- End Message ---
--- Begin Message ---
Source: dwarves
Source-Version: 1.24-4.1
Done: Salvatore Bonaccorso <[email protected]>
We believe that the bug you reported is fixed in the latest version of
dwarves, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to [email protected],
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Salvatore Bonaccorso <[email protected]> (supplier of updated dwarves package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [email protected])
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Format: 1.8
Date: Tue, 02 May 2023 20:37:16 +0200
Source: dwarves
Architecture: source
Version: 1.24-4.1
Distribution: unstable
Urgency: medium
Maintainer: Thomas Girard <[email protected]>
Changed-By: Salvatore Bonaccorso <[email protected]>
Closes: 1033301
Changes:
dwarves (1.24-4.1) unstable; urgency=medium
.
* Non-maintainer upload.
* dwarves: Zero-initialize struct cu in cu__new() to prevent incorrect BTF
types.
Fixes BTF deduplication issues causing arm64 kernel size increase.
Thanks to Aurelien Jarno (Closes: #1033301)
Checksums-Sha1:
2caf173f59f906b972d9c0a631bacbdaf4d157e2 2363 dwarves_1.24-4.1.dsc
26026ac1a7d0a9f7ccd5a0d079b8a64a616f202a 21272 dwarves_1.24-4.1.debian.tar.xz
Checksums-Sha256:
206bf882fc468e74f4a8ee8a5817f377961121ab9329aa30da8224c7141117c1 2363
dwarves_1.24-4.1.dsc
87fdb08b0b0fdace77f36e2b00bb7bc277dd9037270b553ea4ce9b16b6125bdd 21272
dwarves_1.24-4.1.debian.tar.xz
Files:
d3e5f2666e817568739e04c526908d90 2363 utils optional dwarves_1.24-4.1.dsc
bdbbc400b508d44cd1728cdd2ede9f29 21272 utils optional
dwarves_1.24-4.1.debian.tar.xz
-----BEGIN PGP SIGNATURE-----
iQKmBAEBCgCQFiEERkRAmAjBceBVMd3uBUy48xNDz0QFAmRRWdBfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDQ2
NDQ0MDk4MDhDMTcxRTA1NTMxRERFRTA1NENCOEYzMTM0M0NGNDQSHGNhcm5pbEBk
ZWJpYW4ub3JnAAoJEAVMuPMTQ89EBmoP+QHcFxDnaHJm9POXLhT3x9EJia4nnS4B
WxJIMYbsLVWAjHZGObwxsqkvHGFI6IxdKJpje8hrF8tjl4TM4quSch9f/X8tdJm8
wnQWi1O+LvQ6crysWlDzvpFb5alei77aPfwqMgpSbvstwiKBv7kUwFbs4NBeYshM
z202wPX8U4GsY6TpfNSuCnv1zxNxWlA2kZS+jwY9pPvnbKYtwtaPjEXEDYgSySKb
wE/i58LEKL01Ue4+UoSv7yMvXVAotgCf0varROijgFaVhHPt/etGkaMgj4urVxrO
empx96LjhNalOvyt0QXaojAGSio0ex3lbaIHoc5KP4tQD8Qa8RstgzO1wWM641/d
Lr3ZwaTrw4cAiwdjY9Wij+F5oktmuIc3fzGyuLdZHiYTph2WxvMBVCh/8yzfB8qM
+YNs2NK4pbfl1f+25tDi2aYEPsod0k/2IXO04eBN1ZH3hody6GFAyyN+HSJ2HrcY
jp96G90JZtCk+xTM3CZC5p47LMiXVs1McKPsmsuvkc+ApvdBHwF8Y4XfI0faTQOH
Jt119blZAEX21NPAPjVsrtDhUT4s9sN8VDK10AK3BALMt4AVXIBEgGcIJMHt/kiR
IyQZkp79DaEAMRXBlNNsourfBykd/79j4Cydhd7Egl48SilWdbDtTWhPvNihHUjx
Fvk52fJ8cQ4y
=ALLP
-----END PGP SIGNATURE-----
--- End Message ---
