c++: Internal error: Killed: 9 (program ld)
Hello All, I have a problem with building CURRENT tree (rev. 213491). Below is a command which fails: r...@csx-spb-freebsd9 11:04:40 /usr/src/obj/usr/src/usr.bin/clang/clang # [0] c++ -O2 -pipe -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/include -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/tools/driver -I. -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\amd64-undermydesk-freebsd9.0\ -fno-exceptions -fno-rtti -g -O0 -fstack-protector -g -O0 -o clang cc1_main.o cc1as_main.o driver.o /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangfrontendtool/libclangfrontendtool.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangfrontend/libclangfrontend.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangdriver/libclangdriver.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangserialization/libclangserialization.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangcodegen/libclangcodegen.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangparse/libclangparse.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangsema/libclangsema.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangchecker/libclangchecker.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclanganalysis/libclanganalysis.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangindex/libclangindex.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangrewrite/libclangrewrite.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangast/libclangast.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclanglex/libclanglex.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangbasic/libclangbasic.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvminstcombine/libllvminstcombine.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmipo/libllvmipo.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmbitwriter/libllvmbitwriter.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmbitreader/libllvmbitreader.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpccodegen/libllvmpowerpccodegen.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpcasmprinter/libllvmpowerpcasmprinter.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpcinfo/libllvmpowerpcinfo.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86asmparser/libllvmx86asmparser.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86disassembler/libllvmx86disassembler.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86codegen/libllvmx86codegen.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86asmprinter/libllvmx86asmprinter.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86info/libllvmx86info.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipsasmprinter/libllvmmipsasmprinter.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipscodegen/libllvmmipscodegen.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipsinfo/libllvmmipsinfo.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmasmparser/libllvmarmasmparser.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmcodegen/libllvmarmcodegen.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmasmprinter/libllvmarmasmprinter.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmasmparser/libllvmasmparser.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmselectiondag/libllvmselectiondag.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmasmprinter/libllvmasmprinter.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmcodegen/libllvmcodegen.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmscalaropts/libllvmscalaropts.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmtransformutils/libllvmtransformutils.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmc/libllvmmc.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmcparser/libllvmmcparser.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmipa/libllvmipa.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmanalysis/libllvmanalysis.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmtarget/libllvmtarget.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmc/libllvmmc.a
Re: c++: Internal error: Killed: 9 (program ld)
On 2010-10-07 09:27, Dmitry Krivenok wrote: c++: Internal error: Killed: 9 (program ld) Please submit a full bug report. SeeURL:http://gcc.gnu.org/bugs.html for instructions. r...@csx-spb-freebsd9 11:12:52 /usr/src/obj/usr/src/usr.bin/clang/clang # [1] Have anyone seen this problem before? Any workarounds? Should I go ahead and submit gcc bug? This is 'ld' dying, not gcc. As to what the cause of the problem is, I have no idea, since it links fine here, I just tested it. Can you try appending -Wl,--verbose to your link command line, and post the output somewhere? Alternatively, add -v to the command line, figure out what arguments c++ calls ld with, and run that command separately under gdb. E.g. it should run something similar to (formatted for clarity): /usr/obj/usr/src/tmp/usr/bin/ld \ --eh-frame-hdr \ -V \ -dynamic-linker /libexec/ld-elf.so.1 \ -o clang \ /usr/obj/usr/src/tmp/usr/lib/crt1.o \ /usr/obj/usr/src/tmp/usr/lib/crti.o \ /usr/obj/usr/src/tmp/usr/lib/crtbegin.o \ -L/usr/obj/usr/src/tmp/usr/lib \ -L/usr/obj/usr/src/tmp/usr/lib \ cc1_main.o \ cc1as_main.o \ driver.o \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangfrontendtool/libclangfrontendtool.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangfrontend/libclangfrontend.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangdriver/libclangdriver.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangserialization/libclangserialization.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangcodegen/libclangcodegen.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangparse/libclangparse.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangsema/libclangsema.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangchecker/libclangchecker.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclanganalysis/libclanganalysis.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangindex/libclangindex.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangrewrite/libclangrewrite.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangast/libclangast.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclanglex/libclanglex.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangbasic/libclangbasic.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvminstcombine/libllvminstcombine.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmipo/libllvmipo.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmbitwriter/libllvmbitwriter.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmbitreader/libllvmbitreader.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpccodegen/libllvmpowerpccodegen.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpcasmprinter/libllvmpowerpcasmprinter.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpcinfo/libllvmpowerpcinfo.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86asmparser/libllvmx86asmparser.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86disassembler/libllvmx86disassembler.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86codegen/libllvmx86codegen.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86asmprinter/libllvmx86asmprinter.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86info/libllvmx86info.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipsasmprinter/libllvmmipsasmprinter.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipscodegen/libllvmmipscodegen.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipsinfo/libllvmmipsinfo.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmasmparser/libllvmarmasmparser.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmcodegen/libllvmarmcodegen.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmasmprinter/libllvmarmasmprinter.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmasmparser/libllvmasmparser.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmselectiondag/libllvmselectiondag.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmasmprinter/libllvmasmprinter.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmcodegen/libllvmcodegen.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmscalaropts/libllvmscalaropts.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmtransformutils/libllvmtransformutils.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmc/libllvmmc.a \
Re: c++: Internal error: Killed: 9 (program ld)
I run ld under gdb and found the place where it fails: r...@csx-spb-freebsd9 14:34:22 /usr/src/obj/usr/src/usr.bin/clang/clang # [137] gdb --args /usr/bin/ld --eh-frame-hdr -V -dynamic-linker /libexec/ld-elf.so.1 -o clang /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib -L/usr/lib cc1_main.o cc1as_main.o driver.o /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangfrontendtool/libclangfrontendtool.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangfrontend/libclangfrontend.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangdriver/libclangdriver.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangserialization/libclangserialization.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangcodegen/libclangcodegen.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangparse/libclangparse.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangsema/libclangsema.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangchecker/libclangchecker.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclanganalysis/libclanganalysis.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangindex/libclangindex.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangrewrite/libclangrewrite.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangast/libclangast.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclanglex/libclanglex.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangbasic/libclangbasic.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvminstcombine/libllvminstcombine.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmipo/libllvmipo.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmbitwriter/libllvmbitwriter.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmbitreader/libllvmbitreader.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpccodegen/libllvmpowerpccodegen.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpcasmprinter/libllvmpowerpcasmprinter.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpcinfo/libllvmpowerpcinfo.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86asmparser/libllvmx86asmparser.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86disassembler/libllvmx86disassembler.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86codegen/libllvmx86codegen.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86asmprinter/libllvmx86asmprinter.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86info/libllvmx86info.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipsasmprinter/libllvmmipsasmprinter.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipscodegen/libllvmmipscodegen.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipsinfo/libllvmmipsinfo.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmasmparser/libllvmarmasmparser.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmcodegen/libllvmarmcodegen.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmasmprinter/libllvmarmasmprinter.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmasmparser/libllvmasmparser.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmselectiondag/libllvmselectiondag.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmasmprinter/libllvmasmprinter.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmcodegen/libllvmcodegen.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmscalaropts/libllvmscalaropts.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmtransformutils/libllvmtransformutils.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmc/libllvmmc.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmcparser/libllvmmcparser.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmipa/libllvmipa.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmanalysis/libllvmanalysis.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmtarget/libllvmtarget.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmc/libllvmmc.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmcore/libllvmcore.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmarminfo/libllvmarminfo.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmsupport/libllvmsupport.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmsystem/libllvmsystem.a -lstdc++ -lm -lgcc_s -lgcc -lc -lssp_nonshared -lgcc_s -lgcc /usr/lib/crtend.o
Re: c++: Internal error: Killed: 9 (program ld)
On 2010-10-07 12:51, Dmitry Krivenok wrote: I run ld under gdb and found the place where it fails: ... Program received signal SIGKILL, Killed. 0x0042e093 in bfd_elf_final_link (abfd=0x800915140, info=0x66c900) at /usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elflink.c:7247 7247 ext_size = elf_section_data (sec)-rel_hdr.sh_size; Since you are getting SIGKILL, not SIGSEGV, it suggests that you may be running out of memory, and ld is killed. Can you check memory/swap usage during this linking? You should also see messages in the system logs, if programs are killed because of memory exhaustion. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: c++: Internal error: Killed: 9 (program ld)
Yes, you are right. I see a lot of messages like below in dmesg output: swap_pager_getswapspace(5): failed swap_pager_getswapspace(2): failed swap_pager_getswapspace(2): failed swap_pager_getswapspace(2): failed swap_pager_getswapspace(2): failed swap_pager_getswapspace(2): failed swap_pager_getswapspace(2): failed swap_pager_getswapspace(2): failed pid 50038 (ld), uid 0, was killed: out of swap space pid 60947 (sshd), uid 1001, was killed: out of swap space swap_pager: out of swap space swap_pager_getswapspace(16): failed pid 50872 (ld), uid 0, was killed: out of swap space swap_pager: out of swap space swap_pager_getswapspace(2): failed pid 51222 (ld), uid 0, was killed: out of swap space swap_pager: out of swap space swap_pager_getswapspace(16): failed pid 51240 (ld), uid 0, was killed: out of swap space Perhaps I just need to add more swap and memory: kri...@csx-spb-freebsd9 15:54:47 ~ $ [0] swapinfo Device 1K-blocks UsedAvail Capacity /dev/da0s1b50 428 100% kri...@csx-spb-freebsd9 15:54:49 ~ $ [0] Thanks! On Thu, Oct 7, 2010 at 3:51 PM, Dimitry Andric d...@freebsd.org wrote: On 2010-10-07 12:51, Dmitry Krivenok wrote: I run ld under gdb and found the place where it fails: ... Program received signal SIGKILL, Killed. 0x0042e093 in bfd_elf_final_link (abfd=0x800915140, info=0x66c900) at /usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elflink.c:7247 7247 ext_size = elf_section_data (sec)-rel_hdr.sh_size; Since you are getting SIGKILL, not SIGSEGV, it suggests that you may be running out of memory, and ld is killed. Can you check memory/swap usage during this linking? You should also see messages in the system logs, if programs are killed because of memory exhaustion. -- Sincerely yours, Dmitry V. Krivenok e-mail: krivenok.dmi...@gmail.com skype: krivenok_dmitry jabber: krivenok_dmi...@jabber.ru icq: 242-526-443 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Move banner to games
On 10/7/10, army.of.root army.of.r...@googlemail.com wrote: On 10\10\02 18:48, Paul B Mahol wrote: On 10/2/10, Brandon Goochjamesbrandongo...@gmail.com wrote: On Sat, Oct 2, 2010 at 7:36 AM, Paul B Maholone...@gmail.com wrote: Hi, I see no point to have it in usr/bin. Cool! This is the first time I've heard of this program! How come the folks at my university who manage the line printers have never let me on to this?! Ahh -- wait a sec -- I'm beginning to see your point about the whole move it to games thing... -Brandon aka The Green Bar Bandit NetBSD and OpenBSD have this version in games and horizontal version of banner in usr/bin. I see no point to have this program(s) in base at all. I will just stop here. Hi, A horizontal version of banner could be nice for motd etc. I like banner. It makes me smile and think that FreeBSD is a cosy place to be. have a nice day :) You have figlet and toilet with other sundry amusements in ports. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Move banner to games
On 10\10\02 18:48, Paul B Mahol wrote: On 10/2/10, Brandon Goochjamesbrandongo...@gmail.com wrote: On Sat, Oct 2, 2010 at 7:36 AM, Paul B Maholone...@gmail.com wrote: Hi, I see no point to have it in usr/bin. Cool! This is the first time I've heard of this program! How come the folks at my university who manage the line printers have never let me on to this?! Ahh -- wait a sec -- I'm beginning to see your point about the whole move it to games thing... -Brandon aka The Green Bar Bandit NetBSD and OpenBSD have this version in games and horizontal version of banner in usr/bin. I see no point to have this program(s) in base at all. I will just stop here. Hi, A horizontal version of banner could be nice for motd etc. I like banner. It makes me smile and think that FreeBSD is a cosy place to be. have a nice day :) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: fcntl always fails to delete lock file, and PID is always -6464
On Oct 5, 2010, at 4:52 PM, Garrett Cooper wrote: On Tue, Oct 5, 2010 at 1:55 AM, Daichi GOTO dai...@ongs.co.jp wrote: On Tue, 5 Oct 2010 01:23:02 -0700 Garrett Cooper gcoo...@freebsd.org wrote: 2010/10/4 Daichi GOTO dai...@ongs.co.jp: Thanks nice test tool :) And at last I got it excepting one mystery! On Mon, 4 Oct 2010 20:17:08 -0700 Garrett Cooper gcoo...@freebsd.org wrote: Following through the same process on FreeBSD... Window 1: $ ls -l /tmp/lockfile ls: /tmp/lockfile: No such file or directory $ ./test_fcntl Window 2: $ ls -l /tmp/lockfile -rwsr-x--- 1 garrcoop wheel 0 Oct 4 20:14 /tmp/lockfile $ ./test_fcntl test_fcntl: fcntl: Resource temporarily unavailable Just my mystery is as follow: Windows 1: % ./test_fcntl My pid: 43490 Windows 2: % ls -l /tmp/lockfile -r-sr-x--- 1 daichi wheel 0 10月 5 15:02 /tmp/lockfile--- is it weird, isn't it? % ./test_fcntl test_fcntl: open: Permission denied % Oops... What's wrong... /tmp is as follow: % mount | grep tmp /dev/ada0s1f on /tmp (ufs, local, noatime, soft-updates) % dumpfs /tmp | grep journal flags soft-updates+journal % And working scene: Windows 2: % chmod u+w /tmp/lockfile % ls -l /tmp/lockfile -rwsr-x--- 1 daichi wheel 0 10月 5 15:22 /tmp/lockfile % ./test_fcntl My pid: 43646 test_fcntl: fcntl[1]: Resource temporarily unavailable PID=43490 has the lock % What's your umask and what are the permissions on /tmp? % ll / | grep tmp drwxrwxrwt 14 root wheel 1024 10月 5 17:19 tmp % umask 022 % rm -f test % touch test % ll | grep test -rw-r--r-- 1 daichi wheel 0 10月 5 17:52 test % The permissions look ok from my perspective, but the umask is different, so you might want to try my umask to make sure that your results match mine (and we need to check the requirements to determine whether or not the behavior for FreeBSD's umask syscall is correct): $ ls -la /tmp/ | head -n 2 total 462686 drwxrwxrwt 51 root wheel 11776 Oct 5 03:11 . $ umask 0022 The results are different on some users, even on the same user! (022 and 0022 shows the same results.) test user: $ rm -f /tmp/lockfile $ ./test_fcntl My pid: 63133 ^C $ ll /tmp/lockfile ---sr- 1 test wheel - 0 Oct 7 23:16 /tmp/lockfile* $ daichi: % rm -f /tmp/lockfile % ./test_fcntl My pid: 63140 ^C % ll /tmp/lockfile ---Sr-x--- 1 daichi wheel 0 10月 7 23:17 /tmp/lockfile % But above daichi's result was ---sr- as the same as test user. After some operation, it turns into returing ---Sr-x---. I didn't remember what operation did that. root: # rm -f /tmp/lockfile # ./test_fcntl My pid: 63147 ^C # ls -l /tmp/lockfile --wSr-S--- 1 root wheel 0 Oct 7 23:20 /tmp/lockfile # It is mystery. Where and how is /tmp mounted (is it a real partition, what filesystem, etc)? UFS+SUJ+noatime real pertition. I checked atime version, and got the same result. BTW, when I change my umask to match your's I don't get the same results you do on my home machine: Window 1: $ umask 022 $ ./test_fcntl My pid: 17353 Window 2: $ ./test_fcntl My pid: 17356 test_fcntl: fcntl[1]: Resource temporarily unavailable PID=17353 has the lock $ ls -l /tmp/lockfile -rwSr- 1 gcooper wheel 0 Oct 5 07:49 /tmp/lockfile Just to note, the tests before were run on the RHEL 4.8 box with the following info, and the FreeBSD box with the following info: Red Hat Enterprise Linux AS release 4 (Nahant Update 8) Linux sjc-lds-102 2.6.9-89.0.11.ELsmp #1 SMP Mon Aug 31 11:00:34 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux FreeBSD bioshock.cisco.com 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r211767M: Sat Aug 28 00:28:45 PDT 2010 garrc...@bioshock.cisco.com:/usr/obj/usr/src/sys/BIOSHOCK amd64 The tests above were run on a FreeBSD box with the following info: FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #9 r211309M: Thu Aug 19 22:50:36 PDT 2010 r...@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 On bayonetta /tmp is SUJ backed (probably should change that though), and on bioshock it's not SUJ backed. Thanks! -Garrett Still now, I couldn't find the cause of this issue, but it's ok by code following, and program should set permission at creating time I guess. fd = open(/tmp/lockfile, O_CREAT|O_WRONLY,0600); ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: fcntl always fails to delete lock file, and PID is always -6464
On Oct 5, 2010, at 7:09 PM, Garrett Cooper wrote: On Tue, Oct 5, 2010 at 8:58 AM, Garrett Cooper gcoo...@freebsd.org wrote: On Tue, Oct 5, 2010 at 7:52 AM, Garrett Cooper gcoo...@freebsd.org wrote: On Tue, Oct 5, 2010 at 1:55 AM, Daichi GOTO dai...@ongs.co.jp wrote: On Tue, 5 Oct 2010 01:23:02 -0700 Garrett Cooper gcoo...@freebsd.org wrote: 2010/10/4 Daichi GOTO dai...@ongs.co.jp: Thanks nice test tool :) And at last I got it excepting one mystery! On Mon, 4 Oct 2010 20:17:08 -0700 Garrett Cooper gcoo...@freebsd.org wrote: Following through the same process on FreeBSD... Window 1: $ ls -l /tmp/lockfile ls: /tmp/lockfile: No such file or directory $ ./test_fcntl Window 2: $ ls -l /tmp/lockfile -rwsr-x--- 1 garrcoop wheel 0 Oct 4 20:14 /tmp/lockfile $ ./test_fcntl test_fcntl: fcntl: Resource temporarily unavailable Just my mystery is as follow: Windows 1: % ./test_fcntl My pid: 43490 Windows 2: % ls -l /tmp/lockfile -r-sr-x--- 1 daichi wheel 0 10月 5 15:02 /tmp/lockfile--- is it weird, isn't it? % ./test_fcntl test_fcntl: open: Permission denied % Oops... What's wrong... /tmp is as follow: % mount | grep tmp /dev/ada0s1f on /tmp (ufs, local, noatime, soft-updates) % dumpfs /tmp | grep journal flags soft-updates+journal % And working scene: Windows 2: % chmod u+w /tmp/lockfile % ls -l /tmp/lockfile -rwsr-x--- 1 daichi wheel 0 10月 5 15:22 /tmp/lockfile % ./test_fcntl My pid: 43646 test_fcntl: fcntl[1]: Resource temporarily unavailable PID=43490 has the lock % What's your umask and what are the permissions on /tmp? % ll / | grep tmp drwxrwxrwt 14 root wheel 1024 10月 5 17:19 tmp % umask 022 % rm -f test % touch test % ll | grep test -rw-r--r-- 1 daichi wheel 0 10月 5 17:52 test % The permissions look ok from my perspective, but the umask is different, so you might want to try my umask to make sure that your results match mine (and we need to check the requirements to determine whether or not the behavior for FreeBSD's umask syscall is correct): $ ls -la /tmp/ | head -n 2 total 462686 drwxrwxrwt 51 root wheel 11776 Oct 5 03:11 . $ umask 0022 Where and how is /tmp mounted (is it a real partition, what filesystem, etc)? BTW, when I change my umask to match your's I don't get the same results you do on my home machine: Window 1: $ umask 022 $ ./test_fcntl My pid: 17353 Window 2: $ ./test_fcntl My pid: 17356 test_fcntl: fcntl[1]: Resource temporarily unavailable PID=17353 has the lock $ ls -l /tmp/lockfile -rwSr- 1 gcooper wheel 0 Oct 5 07:49 /tmp/lockfile Just to note, the tests before were run on the RHEL 4.8 box with the following info, and the FreeBSD box with the following info: Red Hat Enterprise Linux AS release 4 (Nahant Update 8) Linux sjc-lds-102 2.6.9-89.0.11.ELsmp #1 SMP Mon Aug 31 11:00:34 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux FreeBSD bioshock.cisco.com 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r211767M: Sat Aug 28 00:28:45 PDT 2010 garrc...@bioshock.cisco.com:/usr/obj/usr/src/sys/BIOSHOCK amd64 The tests above were run on a FreeBSD box with the following info: FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #9 r211309M: Thu Aug 19 22:50:36 PDT 2010 r...@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 On bayonetta /tmp is SUJ backed (probably should change that though), and on bioshock it's not SUJ backed. And while this might be a good mental exercise, I think we're missing the original point of your bug: You were getting ECONNREFUSED because a socket was in `use', even though all instances of mozc_server were dead (at least that's the case with me). So the question I guess that's worth asking is: Statement incorrect: socket wasn't in use. The logic needs to be rewritten to account for this case and setup the socket again if this occurs. It would be a good idea to do this if the file wasn't locked. Maybe behavior difference of fcntl when called with F_SETLN or F_GETLN you found is the answer of this issue. I'll try to check it out. Thanks! And I'll try to treat correct l_pid when called with F_SETLN. I guess this change will be benefits for other applications that use fcntl(2) like mozc_server does. 1. What process/application does it need to establish a Unix style socket with? 2. Why isn't that socket being cleaned up by the OS at exit? Thanks! -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Move banner to games
In message 4cadc453.7010...@googlemail.com, army.of.root writes: On 10\10\02 18:48, Paul B Mahol wrote: On 10/2/10, Brandon Goochjamesbrandongo...@gmail.com wrote: On Sat, Oct 2, 2010 at 7:36 AM, Paul B Maholone...@gmail.com wrote: Hi, I see no point to have it in usr/bin. Cool! This is the first time I've heard of this program! How come the folks at my university who manage the line printers have never let me on to this?! Ahh -- wait a sec -- I'm beginning to see your point about the whole move it to games thing... -Brandon aka The Green Bar Bandit NetBSD and OpenBSD have this version in games and horizontal version of banner in usr/bin. I see no point to have this program(s) in base at all. I will just stop here. Hi, A horizontal version of banner could be nice for motd etc. I like banner. It makes me smile and think that FreeBSD is a cosy place to be. It's been in the base for decades. People used it to print banners on reports, before laser and ink jet printers were around, when tractor feed printers ruled. Banner was more than just a game. People used it for production work. I suppose you could still use it for its intended purpose today however with the graphical tools we have today it's a little archaic. Having said that, it doesn't take up a lot of space and should probably remain where it is. BTW, I'm of the age where I did use it and tools like it (on the IBM mainframe) for real work. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org e**(i*pi)+1=0 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Move banner to games
In message 4cadc453.7010...@googlemail.com, army.of.root writes: On 10\10\02 18:48, Paul B Mahol wrote: On 10/2/10, Brandon Goochjamesbrandongo...@gmail.com wrote: On Sat, Oct 2, 2010 at 7:36 AM, Paul B Maholone...@gmail.com wrote: Hi, I see no point to have it in usr/bin. Cool! This is the first time I've heard of this program! How come the folks at my university who manage the line printers have never let me on to this?! Ahh -- wait a sec -- I'm beginning to see your point about the whole move it to games thing... -Brandon aka The Green Bar Bandit NetBSD and OpenBSD have this version in games and horizontal version of banner in usr/bin. I see no point to have this program(s) in base at all. I will just stop here. Hi, A horizontal version of banner could be nice for motd etc. I like banner. It makes me smile and think that FreeBSD is a cosy place to be. It's been in the base for decades. People used it to print banners on reports, before laser and ink jet printers were around, when tractor feed printers ruled. Banner was more than just a game. People used it for production work. I suppose you could still use it for its intended purpose today however with the graphical tools we have today it's a little archaic. Having said that, it doesn't take up a lot of space and should probably remain where it is. BTW, I'm of the age where I did use it and tools like it (on the IBM mainframe) for real work. ah memories, I had the walls of my office covered with pi with some very long precision :-) danny ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Move banner to games
Date: Thu, 07 Oct 2010 16:49:43 +0200 From: Daniel Braniss da...@cs.huji.ac.il Sender: owner-freebsd-curr...@freebsd.org In message 4cadc453.7010...@googlemail.com, army.of.root writes: On 10\10\02 18:48, Paul B Mahol wrote: On 10/2/10, Brandon Goochjamesbrandongo...@gmail.com wrote: On Sat, Oct 2, 2010 at 7:36 AM, Paul B Maholone...@gmail.com wrote: Hi, I see no point to have it in usr/bin. Cool! This is the first time I've heard of this program! How come the folks at my university who manage the line printers have never let me on to this?! Ahh -- wait a sec -- I'm beginning to see your point about the whole move it to games thing... -Brandon aka The Green Bar Bandit NetBSD and OpenBSD have this version in games and horizontal version of banner in usr/bin. I see no point to have this program(s) in base at all. I will just stop here. Hi, A horizontal version of banner could be nice for motd etc. I like banner. It makes me smile and think that FreeBSD is a cosy place to be. It's been in the base for decades. People used it to print banners on reports, before laser and ink jet printers were around, when tractor feed printers ruled. Banner was more than just a game. People used it for production work. I suppose you could still use it for its intended purpose today however with the graphical tools we have today it's a little archaic. Having said that, it doesn't take up a lot of space and should probably remain where it is. BTW, I'm of the age where I did use it and tools like it (on the IBM mainframe) for real work. ah memories, I had the walls of my office covered with pi with some very long precision :-) I'm so sorry. I'm more prone to remember the ASCII rendering of the artwork of rather long images from a popular magazine which would certainly (and properly) be unacceptble in the workplace today. :-) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
acpi_ec: request for review and testing
FYI: http://article.gmane.org/gmane.os.freebsd.devel.acpi/6440 If you can test and would like to report, please followup to that thread on acpi@ mailing list. Please do not followup to this post. Thanks! -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: minidump size on amd64
on 01/10/2010 10:43 Andriy Gapon said the following: The idea. We dump contiguously only pages with PDEs (which means both valid and invalid PDEs), valid pages with PTEs are dumped the same way as data physical pages (i.e. via dump_add_page, etc); no fake PTEs for 2MB pages. PDE area of the dump takes about 20MB as opposed to 1GB for PTE area (the math is obvious, but just in case). libkva is changed to treat former PTE area as PDE area and is also taught to understand PG_PS in PDE. There is now an overhead of having to first read a PTE page in V-to-P-to-offset lookup for !PG_PS case. Perhaps we could cache all PTEs in memory and have a lookup table for them, but I didn't bother with this possibly premature optimization at this time. There is an unrelated change in minidumpsys - bitmap_frozen. I had to do it despite having a patch in my local tree to stop other CPUs on panic-dump. Code in dump path (peripheral disk driver, CAM, SIM driver, something else?) seems to do some memory allocations and change dump bitmap, which leads to a mismatch between dump size and dump bitmap; and also potentially to inconsistencies in the bitmap itself. So I decided that it's a good idea to freeze the bitmap once we decided what pages we want to dump. Some variables and structure fields with 'pte' in them should probably be renamed to have 'pde' instead. Here's an updated patch: http://people.freebsd.org/~avg/amd64-minidump.3.diff I went ahead and changed 'pte' to 'pde' in various names. Also, I ditched somewhat questionable bitmap_frozen approach and instead opted for restarting a dump on a size mismatch. This was suggested by k...@. Garret Cooper has pointed out some problems with bitmap_frozen approach. I think that actual problem was a scenario where a dump is done, then the system is allowed to continue and then another dump is done. An exotic case perhaps? :-) One probably desirable feature that is missing is backward compatibility in libkvm. If that is a showstopper, then I'll have to work on preserving it. As usual, I will appreciate any feedback - reviews, testing, etc. Thanks! -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
panic_cpu should be volatile
panic_cpu variable in kern_shutdown.c should be volatile otherwise it's cached in a register in the innermost while-loop in this code (observed on amd64 with base gcc and -O2): if (panic_cpu != PCPU_GET(cpuid)) while (atomic_cmpset_int(panic_cpu, NOCPU, PCPU_GET(cpuid)) == 0) while (panic_cpu != NOCPU) ; /* nothing */ The patch is here: http://people.freebsd.org/~avg/panic_cpu.diff I also took a liberty to move the variable into the scope of panic() functions as it doesn't seem to be useful outside of it. But this is not necessary, of course. Big thanks to mdf@ for the hint and to kib@ and kan@ for memory model expertise. P.S. The assembly: .loc 1 544 0 movlpanic_cpu(%rip), %eax .LVL134: .p2align 4,,7 .L210: cmpl$255, %eax jne .L210 jmp .L225 -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
HEADS UP: device name checking on device registration
Since r213526 device names are checked on device registration. That is, if you call a make_dev*() function with an invalid device name, a panic will occur by default. For make_dev_credf(9) or make_dev_p(9) you can specify the MAKEDEV_CHECKNAME flag to get an error return instead of a panic. Invalid names are as follows: - empty name - names longer than SPECNAMELEN - names containing . or .. path component - names ending with '/' - already existing device names So, if you see a bad si_name panic you may have encountered a driver bug. Currently several GEOM classes (notably geom_label) allow to create devices with invalid names. Below is a link to a patch which converts g_dev_taste() to use make_dev_p() with MAKEDEV_CHECKNAME flag. It's not a complete solution and essentially changes the panic to a printf. http://people.freebsd.org/~jh/patches/geom_dev-checkname.diff -- Jaakko ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Move banner to games
In message 20101007154058.e68d71c...@ptavv.es.net, Kevin Oberman writes: Date: Thu, 07 Oct 2010 16:49:43 +0200 From: Daniel Braniss da...@cs.huji.ac.il Sender: owner-freebsd-curr...@freebsd.org In message 4cadc453.7010...@googlemail.com, army.of.root writes: On 10\10\02 18:48, Paul B Mahol wrote: On 10/2/10, Brandon Goochjamesbrandongo...@gmail.com wrote: On Sat, Oct 2, 2010 at 7:36 AM, Paul B Maholone...@gmail.com wrot e: Hi, I see no point to have it in usr/bin. Cool! This is the first time I've heard of this program! How come th e folks at my university who manage the line printers have never let m e on to this?! Ahh -- wait a sec -- I'm beginning to see your point about the whole move it to games thing... -Brandon aka The Green Bar Bandit NetBSD and OpenBSD have this version in games and horizontal version of banner in usr/bin. I see no point to have this program(s) in base at all. I will just stop here. Hi, A horizontal version of banner could be nice for motd etc. I like banner. It makes me smile and think that FreeBSD is a cosy place to be. It's been in the base for decades. People used it to print banners on reports, before laser and ink jet printers were around, when tractor fee d printers ruled. Banner was more than just a game. People used it for production work. I suppose you could still use it for its intended purpos e today however with the graphical tools we have today it's a little archai c. Having said that, it doesn't take up a lot of space and should probably remain where it is. BTW, I'm of the age where I did use it and tools like it (on the IBM mainframe) for real work. ah memories, I had the walls of my office covered with pi with some very lo ng precision :-) I'm so sorry. I'm more prone to remember the ASCII rendering of the artwork of rather long images from a popular magazine which would certainly (and properly) be unacceptble in the workplace today. :-) I can recall my first exposure to ASCII art. I was 17 in Computing Science class in high school. A friend had brought in some artwork his brother had printed on the mainframe at the University of Alberta. The source was a Fortran program with a huge number of punched cards as input. It certainly wouldn't be accepted anywhere here either. What I found quite intriguing was the ASCII art produced by arcane single line APL programs. You could pack a lot of function into a very few bytes of code. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org e**(i*pi)+1=0 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on sparc64/sparc64
TB --- 2010-10-07 16:53:41 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-10-07 16:53:41 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2010-10-07 16:53:41 - cleaning the object tree TB --- 2010-10-07 16:56:13 - cvsupping the source tree TB --- 2010-10-07 16:56:13 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2010-10-07 17:00:56 - building world TB --- 2010-10-07 17:00:56 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-07 17:00:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-07 17:00:56 - TARGET=sparc64 TB --- 2010-10-07 17:00:56 - TARGET_ARCH=sparc64 TB --- 2010-10-07 17:00:56 - TZ=UTC TB --- 2010-10-07 17:00:56 - __MAKE_CONF=/dev/null TB --- 2010-10-07 17:00:56 - cd /src TB --- 2010-10-07 17:00:56 - /usr/bin/make -B buildworld World build started on Thu Oct 7 17:00:57 UTC 2010 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Thu Oct 7 21:50:14 UTC 2010 TB --- 2010-10-07 21:50:14 - generating LINT kernel config TB --- 2010-10-07 21:50:14 - cd /src/sys/sparc64/conf TB --- 2010-10-07 21:50:14 - /usr/bin/make -B LINT TB --- 2010-10-07 21:50:15 - building LINT kernel TB --- 2010-10-07 21:50:15 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-07 21:50:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-07 21:50:15 - TARGET=sparc64 TB --- 2010-10-07 21:50:15 - TARGET_ARCH=sparc64 TB --- 2010-10-07 21:50:15 - TZ=UTC TB --- 2010-10-07 21:50:15 - __MAKE_CONF=/dev/null TB --- 2010-10-07 21:50:15 - cd /src TB --- 2010-10-07 21:50:15 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Oct 7 21:50:15 UTC 2010 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64.sparc64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/sparc64.sparc64/src/sys/LINT -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/usb/xhci/../../../dev/usb/controller/xhci_pci.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64.sparc64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/sparc64.sparc64/src/sys/LINT -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/usb/xhci/../../../dev/usb/controller/xhci.c cc1: warnings being treated as errors /src/sys/modules/usb/xhci/../../../dev/usb/controller/xhci.c: In function 'xhci_setup_generic_chain_sub': /src/sys/modules/usb/xhci/../../../dev/usb/controller/xhci.c:1540: warning: right shift count = width of type /src/sys/modules/usb/xhci/../../../dev/usb/controller/xhci.c:1540: warning: right shift count = width of type /src/sys/modules/usb/xhci/../../../dev/usb/controller/xhci.c:1540: warning: left shift count = width of type /src/sys/modules/usb/xhci/../../../dev/usb/controller/xhci.c:1540: warning: left shift count = width of type *** Error code 1 Stop in /src/sys/modules/usb/xhci. *** Error code 1 Stop in /src/sys/modules/usb. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-10-07 23:16:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-10-07 23:16:44 - ERROR: failed to build lint kernel TB --- 2010-10-07 23:16:44 - 4033.84 user 12539.78 system 22983.48 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on sparc64/sun4v
TB --- 2010-10-07 18:54:35 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-10-07 18:54:35 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2010-10-07 18:54:35 - cleaning the object tree TB --- 2010-10-07 18:56:48 - cvsupping the source tree TB --- 2010-10-07 18:56:49 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2010-10-07 19:01:52 - building world TB --- 2010-10-07 19:01:52 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-07 19:01:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-07 19:01:52 - TARGET=sun4v TB --- 2010-10-07 19:01:52 - TARGET_ARCH=sparc64 TB --- 2010-10-07 19:01:52 - TZ=UTC TB --- 2010-10-07 19:01:52 - __MAKE_CONF=/dev/null TB --- 2010-10-07 19:01:52 - cd /src TB --- 2010-10-07 19:01:52 - /usr/bin/make -B buildworld World build started on Thu Oct 7 19:01:53 UTC 2010 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Thu Oct 7 23:42:31 UTC 2010 TB --- 2010-10-07 23:42:31 - generating LINT kernel config TB --- 2010-10-07 23:42:31 - cd /src/sys/sun4v/conf TB --- 2010-10-07 23:42:31 - /usr/bin/make -B LINT TB --- 2010-10-07 23:42:31 - building LINT kernel TB --- 2010-10-07 23:42:31 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-07 23:42:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-07 23:42:31 - TARGET=sun4v TB --- 2010-10-07 23:42:31 - TARGET_ARCH=sparc64 TB --- 2010-10-07 23:42:31 - TZ=UTC TB --- 2010-10-07 23:42:31 - __MAKE_CONF=/dev/null TB --- 2010-10-07 23:42:31 - cd /src TB --- 2010-10-07 23:42:31 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Oct 7 23:42:31 UTC 2010 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sun4v.sparc64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/sun4v.sparc64/src/sys/LINT -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/usb/xhci/../../../dev/usb/controller/xhci_pci.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sun4v.sparc64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/sun4v.sparc64/src/sys/LINT -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/usb/xhci/../../../dev/usb/controller/xhci.c cc1: warnings being treated as errors /src/sys/modules/usb/xhci/../../../dev/usb/controller/xhci.c: In function 'xhci_setup_generic_chain_sub': /src/sys/modules/usb/xhci/../../../dev/usb/controller/xhci.c:1540: warning: right shift count = width of type /src/sys/modules/usb/xhci/../../../dev/usb/controller/xhci.c:1540: warning: right shift count = width of type /src/sys/modules/usb/xhci/../../../dev/usb/controller/xhci.c:1540: warning: left shift count = width of type /src/sys/modules/usb/xhci/../../../dev/usb/controller/xhci.c:1540: warning: left shift count = width of type *** Error code 1 Stop in /src/sys/modules/usb/xhci. *** Error code 1 Stop in /src/sys/modules/usb. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/sun4v.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-10-08 00:43:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-10-08 00:43:56 - ERROR: failed to build lint kernel TB --- 2010-10-08 00:43:56 - 3953.21 user 12352.39 system 20960.97 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sun4v.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
