|
From: Bart V. A. <bar...@gm...> - 2006-03-25 14:21:09
|
$ svn co svn://svn.valgrind.org/valgrind/trunk valgrind $ cd valgrind/ $ ./autogen.sh $ ./configure --prefix=3D$PWD/inst $ make && make install $ svnversion . 1601:5789 $ inst/bin/valgrind --tool=3Dmemcheck ls Killed $ strace inst/bin/valgrind --tool=3Dmemcheck ls 2>&1 | tail -5 readlink("/proc/self/exe", "/home/bart/software/vg/valgrind/inst/bin/valgrind", 4096) =3D 49 brk(0) =3D 0x804d000 brk(0x806e000) =3D 0x806e000 execve("/home/bart/software/vg/valgrind/inst/lib/valgrind/x86-linux/memchec= k", ["inst/bin/valgrind", "--tool=3Dmemcheck", "ls"], [/* 76 vars */]) =3D 0 +++ killed by SIGKILL +++ |
|
From: Julian S. <js...@ac...> - 2006-03-25 14:26:58
|
No, last night's overnight builds all seem fine. Have you changed to using a kernel which does not have the default 3G+1G split? That's the usual reason for the tool binaries being SIGKILLd at startup. J On Saturday 25 March 2006 14:14, Bart Van Assche wrote: > $ svn co svn://svn.valgrind.org/valgrind/trunk valgrind > $ cd valgrind/ > $ ./autogen.sh > $ ./configure --prefix=$PWD/inst > $ make && make install > $ svnversion . > 1601:5789 > $ inst/bin/valgrind --tool=memcheck ls > Killed > $ strace inst/bin/valgrind --tool=memcheck ls 2>&1 | tail -5 > readlink("/proc/self/exe", > "/home/bart/software/vg/valgrind/inst/bin/valgrind", 4096) = 49 > brk(0) = 0x804d000 > brk(0x806e000) = 0x806e000 > execve("/home/bart/software/vg/valgrind/inst/lib/valgrind/x86-linux/memchec >k", ["inst/bin/valgrind", "--tool=memcheck", "ls"], [/* 76 vars */]) = 0 +++ > killed by SIGKILL +++ |
|
From: Bart V. A. <bar...@gm...> - 2006-03-25 15:40:56
|
I switched to the 2.6.16 kernel and enabled CONFIG_VMSPLIT_3G_OPT=3Dy inste= ad of the usual CONFIG_VMSPLIT_3G. Probably that's the cause ? I think I will switch back to CONFIG_VMSPLIT_3G. On 3/25/06, Julian Seward <js...@ac...> wrote: > > > No, last night's overnight builds all seem fine. Have you changed > to using a kernel which does not have the default 3G+1G split? > That's the usual reason for the tool binaries being SIGKILLd at > startup. > |
|
From: Julian S. <js...@ac...> - 2006-03-25 16:05:18
|
Alternatively, you can just change the value of valt_load_address_normal in configure.in to something else, like 0x30000000, re-configure, re-build. What layout does CONFIG_VMSPLIT_3G_OPT=y give? Is it a new option in kernel 2.6.16? J On Saturday 25 March 2006 15:40, Bart Van Assche wrote: > I switched to the 2.6.16 kernel and enabled CONFIG_VMSPLIT_3G_OPT=y instead > of the usual CONFIG_VMSPLIT_3G. Probably that's the cause ? I think I will > switch back to CONFIG_VMSPLIT_3G. > > On 3/25/06, Julian Seward <js...@ac...> wrote: > > No, last night's overnight builds all seem fine. Have you changed > > to using a kernel which does not have the default 3G+1G split? > > That's the usual reason for the tool binaries being SIGKILLd at > > startup. |
|
From: Bart V. A. <bar...@gm...> - 2006-03-26 07:25:51
|
Hello Julian,
This config option is new in kernel 2.6.16.
From linux-2.6.16/arch/i386/Kconfig:
choice
depends on EXPERIMENTAL && !X86_PAE
prompt "Memory split"
default VMSPLIT_3G
help
Select the desired split between kernel and user memory.
If the address range available to the kernel is less than the
physical memory installed, the remaining memory will be available
as "high memory". Accessing high memory is a little more costly
than low memory, as it needs to be mapped into the kernel first.
Note that increasing the kernel address space limits the range
available to user programs, making the address space there
tighter. Selecting anything other than the default 3G/1G split
will also likely make your kernel incompatible with binary-only
kernel modules.
If you are not absolutely sure what you are doing, leave this
option alone!
config VMSPLIT_3G
bool "3G/1G user/kernel split"
config VMSPLIT_3G_OPT
bool "3G/1G user/kernel split (for full 1G low memory)"
config VMSPLIT_2G
bool "2G/2G user/kernel split"
config VMSPLIT_1G
bool "1G/3G user/kernel split"
endchoice
config PAGE_OFFSET
hex
default 0xB0000000 if VMSPLIT_3G_OPT
default 0x78000000 if VMSPLIT_2G
default 0x40000000 if VMSPLIT_1G
default 0xC0000000
From linux-2.6.16/include/asm-i386/page.h:
#define __PAGE_OFFSET ((unsigned long)CONFIG_PAGE_OFFSET)
On 3/25/06, Julian Seward <js...@ac...> wrote:
>
>
> Alternatively, you can just change the value of valt_load_address_normal
> in configure.in to something else, like 0x30000000, re-configure,
> re-build.
>
> What layout does CONFIG_VMSPLIT_3G_OPT=3Dy give? Is it a new option
> in kernel 2.6.16?
>
> J
>
> On Saturday 25 March 2006 15:40, Bart Van Assche wrote:
> > I switched to the 2.6.16 kernel and enabled CONFIG_VMSPLIT_3G_OPT=3Dy
> instead
> > of the usual CONFIG_VMSPLIT_3G. Probably that's the cause ? I think I
> will
> > switch back to CONFIG_VMSPLIT_3G.
> >
> > On 3/25/06, Julian Seward <js...@ac...> wrote:
> > > No, last night's overnight builds all seem fine. Have you changed
> > > to using a kernel which does not have the default 3G+1G split?
> > > That's the usual reason for the tool binaries being SIGKILLd at
> > > startup.
>
|