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
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
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
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
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
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
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
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
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
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!
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.
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
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
___
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
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)
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.
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
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 -
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 -
19 matches
Mail list logo
