Can not build arch v6.2.* linux. Does that much swap space required?
Hello, I haven't tried all the 6.2.*. Only some of the earliest, and some of the latest. v6.2.9, at this time. I could build the earliest v6.1.*. And also v6.1.12. Which is arch latest v6.1.*, doesn't it? I got what looks to me a similar issue with v6.1.7, if I remember correctly. As of v6.2.7 and v6.2.9, I get: $ cat -n linux-6.2.9.arch1-1-x86_64-build.log | tail 19288 AR arch/x86/video/built-in.a 19289 AR built-in.a 19290 AR vmlinux.a 19291 LD vmlinux.o 19292 vmlinux.o: warning: objtool: hyperv_init+0x42f: unreachable instruction 19293 make[1]: *** Deleting file 'vmlinux.o' 19294 make[1]: *** [scripts/Makefile.vmlinux_o:61: vmlinux.o] Interrupt 19295 make: *** [Makefile:1245: vmlinux_o] Interrupt 19296 19297 ==> ERROR: Aborted by user! Exiting... After it stalled for a long time at line #19291, or at line #19292, I interrupted it, ^c, manually. I forgot to look at the resource usage before interrupting v6.2.9 build. For some of the prevoius versions it happend, I saw the LD proccess consumed almost all of the machine free memory. And also a lot of swap. Which happend right at the LD operation, not before. It is only a desktop, Only 4G RAM. I am also confused about the unreachable warning. I think I saw it earlier only once. Possibly at some later v6.2.* version. But I can't find it at any log file. Perhaps I have deleted the file. I am using a local version for PKGBUILD. Does the follwoign diff maters? 63c63 < make all # htmldocs --- > make htmldocs all 195,196c195 < # pkgname=("$pkgbase" "$pkgbase-headers" "$pkgbase-docs") < pkgname=("$pkgbase" "$pkgbase-headers") --- > pkgname=("$pkgbase" "$pkgbase-headers" "$pkgbase-docs") There is also ccache enabled for makepkg. -- u34
On Monday, 3 April 2023 at 08:58 (+0000), u34@net9.ga wrote:
I haven't tried all the 6.2.*. Only some of the earliest, and some of the latest. v6.2.9, at this time. I could build the earliest v6.1.*. And also v6.1.12. Which is arch latest v6.1.*, doesn't it? I got what looks to me a similar issue with v6.1.7, if I remember correctly. As of v6.2.7 and v6.2.9, I get:
$ cat -n linux-6.2.9.arch1-1-x86_64-build.log | tail 19288 AR arch/x86/video/built-in.a 19289 AR built-in.a 19290 AR vmlinux.a 19291 LD vmlinux.o 19292 vmlinux.o: warning: objtool: hyperv_init+0x42f: unreachable instruction 19293 make[1]: *** Deleting file 'vmlinux.o' 19294 make[1]: *** [scripts/Makefile.vmlinux_o:61: vmlinux.o] Interrupt 19295 make: *** [Makefile:1245: vmlinux_o] Interrupt 19296 19297 ==> ERROR: Aborted by user! Exiting...
After it stalled for a long time at line #19291, or at line #19292, I interrupted it, ^c, manually. I forgot to look at the resource usage before interrupting v6.2.9 build. For some of the prevoius versions it happend, I saw the LD proccess consumed almost all of the machine free memory. And also a lot of swap. Which happend right at the LD operation, not before. It is only a desktop, Only 4G RAM.
Have you modified the config at all? If you have, seeing the modified config would be helpful. A very sure way to use a lot of memory (well over 4G) at linking is if you have enabled LTO in the kernel config. Perhaps this is the culprit? Jaron
Jaron Kent-Dobias
On Monday, 3 April 2023 at 08:58 (+0000), u34@net9.ga wrote:
I haven't tried all the 6.2.*. Only some of the earliest, and some of the latest. v6.2.9, at this time. I could build the earliest v6.1.*. And also v6.1.12. Which is arch latest v6.1.*, doesn't it? I got what looks to me a similar issue with v6.1.7, if I remember correctly. As of v6.2.7 and v6.2.9, I get:
$ cat -n linux-6.2.9.arch1-1-x86_64-build.log | tail 19288 AR arch/x86/video/built-in.a 19289 AR built-in.a 19290 AR vmlinux.a 19291 LD vmlinux.o 19292 vmlinux.o: warning: objtool: hyperv_init+0x42f: unreachable instruction 19293 make[1]: *** Deleting file 'vmlinux.o' 19294 make[1]: *** [scripts/Makefile.vmlinux_o:61: vmlinux.o] Interrupt 19295 make: *** [Makefile:1245: vmlinux_o] Interrupt 19296 19297 ==> ERROR: Aborted by user! Exiting...
After it stalled for a long time at line #19291, or at line #19292, I interrupted it, ^c, manually. I forgot to look at the resource usage before interrupting v6.2.9 build. For some of the prevoius versions it happend, I saw the LD proccess consumed almost all of the machine free memory. And also a lot of swap. Which happend right at the LD operation, not before. It is only a desktop, Only 4G RAM.
Have you modified the config at all? If you have, seeing the modified config would be helpful.
I have tried v6.2.9 with default arch config. In the past, I used a trimmed down configuration. And got a similar issue starting with some of v6.1.* arch source. With earlier v6.1.*, and before, I always could built arch linux source with my trimmed down configuration. In fact, I was surprised I could built 6.1.12. With my trimmed down configuration, if I remember correctly.
A very sure way to use a lot of memory (well over 4G) at linking is if you have enabled LTO in the kernel config. Perhaps this is the culprit?
Default arch config. No LTO, as far as I can tell. $ grep LTO config CONFIG_ARCH_SUPPORTS_LTO_CLANG=y CONFIG_ARCH_SUPPORTS_LTO_CLANG_THIN=y CONFIG_LTO_NONE=y CONFIG_HID_WALTOP=m
Jaron
-- u34
I saw the LD proccess consumed almost all of the machine free memory. And also a lot of swap. Which happend right at the LD operation, not before. It is only a desktop, Only 4G RAM.
I'm surprised you could've ever compiled a kernel with only 4GB Ram People are talking here about optimisations so it can compile on 32GB machines: https://www.phoronix.com/news/Linux-6.3-objtool -- damjan
On Mon, 2023-04-03 at 11:07 +0200, Damjan Georgievski wrote:
I'm surprised you could've ever compiled a kernel with only 4GB Ram
People are talking here about optimisations so it can compile on 32GB machines: https://www.phoronix.com/news/Linux-6.3-objtool
In this case, while my first guess related to tmpfs is irrelevant, using "make localmodconfig" might help. Disabling tmpfs completely might gain something, keeping a shared RAM framebuffer as small as possible might help.
Damjan Georgievski
I saw the LD proccess consumed almost all of the machine free memory. And also a lot of swap. Which happend right at the LD operation, not before. It is only a desktop, Only 4G RAM.
I'm surprised you could've ever compiled a kernel with only 4GB Ram
People are talking here about optimisations so it can compile on 32GB machines: https://www.phoronix.com/news/Linux-6.3-objtool
It can be an issue of configuration length. Some time ago, after I started to get that problem, I tried the kernel tinyconfig. It got built.
-- damjan
-- u34
Hi, it's much likely that you cannot build a kernel in tmpfs. By default your 4G RAM are 2G tmpfs. However, if you configure to build a slim kernel, it might work, let alone that you should get an "out of space" error, if you run out of space. Swapping by providing way enough swap space never worked for me, if tmpfs didn't provide enough storage space or inodes. If you add something like tmpfs /tmp tmpfs nodev,nosuid,size=3G 0 0 to /etc/fstab it might not help. Better build outside of tmpfs. Since you don't get an "out of space" error message there much likely is another issue. Regards, Ralf -- No Gigbyte support without a Windows installation! This is more than simply not supporting Linux. For Gigabyte motherboard support I need to provide a screenshot of the msinfo32 output. They don't accept providing the information about the used BIOS version and similar without such a screenshot. No msinfo32, no support, even for something unrelated to an installed operating system, like the power-on self-test. However, one of my issues is related to Linux as the PC speaker doesn't work with Linux so I asked support to test if the PC speaker works with Windows as this could be an all OS issue. They didn't check if a PC speaker can be used with Windows.
Ralf Mardorf
Hi,
it's much likely that you cannot build a kernel in tmpfs. By default your 4G RAM are 2G tmpfs. However, if you configure to build a slim kernel, it might work, let alone that you should get an "out of space" error, if you run out of space. Swapping by providing way enough swap space never worked for me, if tmpfs didn't provide enough storage space or inodes.
If you add something like
tmpfs /tmp tmpfs nodev,nosuid,size=3G 0 0
to /etc/fstab it might not help. Better build outside of tmpfs.
Since you don't get an "out of space" error message there much likely is another issue.
I did nothing to make it use tmpfs. Should I explicitly take some actions to get it outside of tmpfs? As I wrote in https://lists.archlinux.org/archives/users/cbdfe95166fd49d4a2c1d93823f416aa/ , before v6.1.6, or so, I could build a much trimmed down configuration. Than too, I took no explicit actions to take it outside of tmpfs. -- u34
Regards, Ralf
-- No Gigbyte support without a Windows installation! This is more than simply not supporting Linux.
For Gigabyte motherboard support I need to provide a screenshot of the msinfo32 output. They don't accept providing the information about the used BIOS version and similar without such a screenshot. No msinfo32, no support, even for something unrelated to an installed operating system, like the power-on self-test. However, one of my issues is related to Linux as the PC speaker doesn't work with Linux so I asked support to test if the PC speaker works with Windows as this could be an all OS issue. They didn't check if a PC speaker can be used with Windows.
On Mon, 2023-04-03 at 10:37 +0000, u34@net9.ga wrote:
I did nothing to make it use tmpfs. Should I explicitly take some actions to get it outside of tmpfs?
Hi, no you don't need to take any action. I suspect my other idea to disable tmpfs entirely is entirely idiotic. $ df -h | grep tmpfs tmpfs 16G 0 16G 0% /dev/shm tmpfs 16G 8.0K 16G 1% /tmp tmpfs 3.2G 64K 3.2G 1% /run/user/1000 ^^^^Used^ Disabling tmpfs would probably even not really free those 72K. If you should share RAM for the framebuffer, reducing the framebuffer size might make a difference. I can't comment on "tinyconfig" or "localmodconfig", but this is what I would try. Regards, Ralf
Ralf Mardorf
On Mon, 2023-04-03 at 10:37 +0000, u34@net9.ga wrote:
I did nothing to make it use tmpfs. Should I explicitly take some actions to get it outside of tmpfs?
Hi,
no you don't need to take any action.
I suspect my other idea to disable tmpfs entirely is entirely idiotic.
$ df -h | grep tmpfs tmpfs 16G 0 16G 0% /dev/shm tmpfs 16G 8.0K 16G 1% /tmp tmpfs 3.2G 64K 3.2G 1% /run/user/1000 ^^^^Used^ Disabling tmpfs would probably even not really free those 72K.
If you should share RAM for the framebuffer, reducing the framebuffer size might make a difference.
I can't comment on "tinyconfig" or "localmodconfig", but this is what I would try.
Hello, I could compile tinyconfig. With localmodconfig, it seems to get nowhwre. I added a lot of swap sapce, more then my total RAM. It seems to use only a tiny part of the swap addition. I don't know what it was exactly doing. I won't be surprised if it mostly transfered data from swap to RAM and vice versa. Doing negliable work, if at all, while swaping in and out. I hope the most beneficial item of this message is to mention the 6GB at the URL in the reply of Damjan Georgievski. https://lists.archlinux.org/archives/users/80dccca1a3964851a69e37d36e681a00/ -> https://www.phoronix.com/news/Linux-6.3-objtool . Though I don't know how much more, or less, than 6GB will be actually required to compile linux for, and on, a low end desktop. -- u34
Regards, Ralf
participants (4)
-
Damjan Georgievski
-
Jaron Kent-Dobias
-
Ralf Mardorf
-
u34＠net9.ga