Bug #1788
closed
x86_64 buildworld broken
0%
Description
Is buildworld on X86_64_GENERIC broken? – When I try to do a "make
buildworld" on a X86_64 box it breaks with:
cc -O -pipe -DTARGET_MACHINE=\"x86_64-pc-dragonflybsd\"
-DHOST_MACHINE=\"x86_64-pc-dragonflybsd\" -I.
-I/usr/src/gnu/usr.bin/cc41/cc1plus//../../../../contrib/gcc-4.1/gcc/cp
-I/usr/obj/usr/src/ctools_x86_64_x86_64/usr/src/gnu/usr.bin/cc41/cc1plus//../cc_prep
-I/usr/src/gnu/usr.bin/cc41/cc1plus//../cc_prep
-I/usr/src/gnu/usr.bin/cc41/cc1plus//../cc_prep/config
-I/usr/src/gnu/usr.bin/cc41/cc1plus//../../../../contrib/gcc_64/usr/src/gnu/usr.bin/cc41/cc1plus//../cc_prep
-I/usr/src/gnu/usr.bin/cc41/cc1plus//../cc_prep
-I/usr/src/gnu/usr.bin/cc41/cc1plus//../cc_prep/config
-I/usr/src/gnu/usr.bin/cc41/cc1plus//../../../../contrib/gcc-4.1/gcc
-I/usr/src/gnu/usr.bin/cc41/cc1plus//../../../../contrib/gcc-4.1/gcc/config
-I/usr/src/gnu/usr.bin/cc41/cc1plus//../../../../contrib/gcc-4.1/include
-I/usr/src/gnu/usr.bin/cc41/cc1plus//../../../../contrib/gcc-4.1/libcpp/include
-DIN_GCC -DHAVE_CONFIG_H
-DPREFIX=\"/usr/obj/usr/src/ctools_x86_64_x86_64/usr\"
-DPREFIX1=\"/usr/obj/usr/src/ctools_x86_64_x86_64/usr\"
-DPREFIX2=\"/usr/obj/usr/src/world_x86_64/usr\"
-I/usr/obj/usr/src/ctools_x86_64_x86_64/usr/src/gnu/usr.bin/cc41/cc1plus//../cc_tools/gen
-c
/usr/obj/usr/src/ctools_x86_64_x86_64/usr/src/gnu/usr.bin/cc41/cc1plus//../cc_tools/gen/insn-attrtab.c
newline inserted
cc: Internal error: Killed: 9 (program cc1)
Please submit a full bug report.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
- Error code 1
- Error code 1
- Error code 1
- Error code 1
- Error code 1
Stop in /usr/src.
My setup is a fresh x86_64 dragonflybsd-2.6.3 HVM/VM on a Xen x86_64
hypervisor. The source was cloned today.
If I boot and install dragonfly from the 2.6.3 i386 iso and sync the
source, buildworld works fine.
Any tips would be appreciated as I'm probably doing something wrong.
Thanks,
Tim
Updated by dillon over 14 years ago
I reproduced the problem on x86_64 with the latest HEAD, so you
don't need to do any more. I will bisect the git repo to track
down where the problem was introduced. It may take a few days,
depending.
-Matt
Updated by Anonymous over 14 years ago
I tried a 2.6.1 iso too, but I still encountered the error.
However, I tried the same buildworld (same image) and it succeeded when
it was on Xen on a Xeon box. The original setup (that doesn't work) is
Xen on Opteron.
According to google references, this error message has been linked to
too much optimization.
Tim
On 6/29/10 9:44 PM, Matthew Dillon wrote:
I reproduced the problem on x86_64 with the latest HEAD, so you
don't need to do any more. I will bisect the git repo to track
down where the problem was introduced. It may take a few days,
depending.-Matt
Updated by dillon over 14 years ago
:I tried a 2.6.1 iso too, but I still encountered the error.
:
:However, I tried the same buildworld (same image) and it succeeded when
:it was on Xen on a Xeon box. The original setup (that doesn't work) is
:Xen on Opteron.
:
:According to google references, this error message has been linked to
:too much optimization.
:
:Tim
Well, in this case I think we have an issue with the kernel code
somewhere in the VM system but I'm having trouble tracking it down.
I'll start some more extensive tests.-Matt
Updated by dillon over 14 years ago
Ok, unfortunately it looks like your problem may be different from
the one we found. We found a corruption issue with the VM page
zeroing code (vm.idlezero_enable sysctl), but that code is not
enabled by default.
The issue with x86_64 might be a VM/HVM issue with 64-bit emulation.-Matt
Updated by marino about 12 years ago
- Description updated (diff)
- Status changed from New to Closed
- Assignee deleted (
0)
long obsolete -- and cc41 isn't even around anymore.
FWIW - that looks like the "out of swap space" error you get when the -j number is too high for the swap space.