Re: what causes error -- ELF interpreter /libexec/ld-elf.so.1 not found

2007-06-14 Thread John Baldwin
On Wednesday 13 June 2007 06:32:42 pm Jin Guojun wrote:
 Umm, the amount of physical memory has no bearing on how the virtual
 address space for userland is laid out.  Do you know what virtual memory
 is and how it works?  Your first e-mail seems to contradict this paragraph
 as in your first e-mail you noted that the physical memory doesn't matter,
 the solution was to not raise MAXDSIZ higher than 1GB and that is consistent
 with running out of virtual address space due to MAXDSIZ reserving too much
 address space for malloc().
   
  No quite clear on this. Does this mean that the MAXDSIZ cannot exceeed 1GB 
regardless
  how many physical memory (say 16 GB) is installed? Then, this is 
definitiely a software bug.
  Then, somewhere the following checking is needed:
  
  #if (MAXDSIZ  1024 * 1024 * 1024)
  #undef   MAXDSIZ
  #define   MAXDSIZ   (1024 * 1024 * 1024)
  #endif

It depends on the app.  Some apps you can crank the malloc space up a whole 
lot.  Also, if you are running FreeBSD/amd64 and running a 32-bit binary 
under freebsd32 emulation, then it has 4GB of VA space rather than 3GB, so 
you can give it more MAXDSIZ.  It's really up to the user to only use a 
maxdsiz that works.  You can also adjust the hard limit before exec'ing a 
process that needs a smaller dsize and leave MAXDSIZ larger for other 
processes.  Since it is dependent on things the compiler can't know about at 
the build time of the kernel, we just let the user set it to whatever and if 
they set it too high things break until they lower it.  You can even set this 
at boot time via 'kern.maxdsiz' tunable in the loader w/o needing to 
recompile.

-- 
John Baldwin
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: what causes error -- ELF interpreter /libexec/ld-elf.so.1 not found

2007-06-13 Thread John Baldwin
On Tuesday 12 June 2007 09:20:02 pm Jin Guojun wrote:
  John Baldwin wrote: 
 On Saturday 09 June 2007 08:53:18 pm Jin Guojun [VFFS] wrote:
   
 I believe that this is a memory sub-system bug somewhere because 
 anything equal to or below 1G
 
 options MAXDSIZ=(1024*1024*1024)
 
 will work regardless how many memory is installed in the system.
 I doubt this could be a hardware related issue although is memory size 
 related.
 
 
 Finally find cause but no idea why -- in kernel configuration, 
 following line causes the problem:
 
options MAXDSIZ=(2097152U*1024)
 
 Can anyone explain why this can cause /libexec/ld-elf.so.1 not seen 
 for some program?
   
 
 This is setting aside 2GB for malloc which leaves only 1GB for all of mmap 
 and 
 stack.  You probably don't have enough address space to map your binary.
   
  This does not quite explain the problem. 
  First of all, the MAXDSIZ is the maximum size for users to set their own 
 datasize limit by 'limit'
  utility.  If user do not set a high limit for datasize, it should not be a 
 problem.

UTSL.  By default proc0 gets a hard limit (lim_max vs lim_cur) of MAXDSIZ,
and the max limit is what the ELF image activator in the kernel uses when
figuring out where to mmap the runtime linker:

/*
 * We load the dynamic linker where a userland call
 * to mmap(0, ...) would put it.  The rationale behind this
 * calculation is that it leaves room for the heap to grow to
 * its maximum allowed size.
 */
addr = round_page((vm_offset_t)imgp-proc-p_vmspace-vm_daddr +
lim_max(imgp-proc, RLIMIT_DATA));

  The second aspect also counters this assumption, for machines that have less 
 than or equal to
  1 GB memory, and setting the MAXDISZ = the maximum memory size will not 
 cause such problem.
  For example, if the physical memory size is 512 MB, and setting 
 MAXDSIZ=(512*1024*1024)
  will not cause this problem. Or if the physical memory is 1GB, setting 
 MAXDSIZ=(1024*1024*1024)
  will not cause the problem either.

Umm, the amount of physical memory has no bearing on how the virtual
address space for userland is laid out.  Do you know what virtual memory
is and how it works?  Your first e-mail seems to contradict this paragraph
as in your first e-mail you noted that the physical memory doesn't matter,
the solution was to not raise MAXDSIZ higher than 1GB and that is consistent
with running out of virtual address space due to MAXDSIZ reserving too much
address space for malloc().

-- 
John Baldwin
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: what causes error -- ELF interpreter /libexec/ld-elf.so.1 not found

2007-06-13 Thread Jin Guojun

   John Baldwin wrote:

On Tuesday 12 June 2007 09:20:02 pm Jin Guojun wrote:
  

 John Baldwin wrote: 
On Saturday 09 June 2007 08:53:18 pm Jin Guojun [VFFS] wrote:
  
I believe that this is a memory sub-system bug somewhere because 
anything equal to or below 1G

options MAXDSIZ=(1024*1024*1024)

will work regardless how many memory is installed in the system.
I doubt this could be a hardware related issue although is memory size 
related.


Finally find cause but no idea why -- in kernel configuration, 
following line causes the problem:

   options MAXDSIZ=(2097152U*1024)

Can anyone explain why this can cause /libexec/ld-elf.so.1 not seen 
for some program?
  

This is setting aside 2GB for malloc which leaves only 1GB for all of mmap and 
stack.  You probably don't have enough address space to map your binary.
  
 This does not quite explain the problem. 
 First of all, the MAXDSIZ is the maximum size for users to set their own datas
ize limit by 'limit'
 utility.  If user do not set a high limit for datasize, it should not be a pro
blem.


UTSL.  By default proc0 gets a hard limit (lim_max vs lim_cur) of MAXDSIZ,
and the max limit is what the ELF image activator in the kernel uses when
figuring out where to mmap the runtime linker:

/*
 * We load the dynamic linker where a userland call
 * to mmap(0, ...) would put it.  The rationale behind this
 * calculation is that it leaves room for the heap to grow to
 * its maximum allowed size.
 */
addr = round_page((vm_offset_t)imgp-proc-p_vmspace-vm_daddr +
lim_max(imgp-proc, RLIMIT_DATA));

  

 The second aspect also counters this assumption, for machines that have less t
han or equal to
 1 GB memory, and setting the MAXDISZ = the maximum memory size will not cause 
such problem.
 For example, if the physical memory size is 512 MB, and setting MAXDSIZ=(512*1
024*1024)
 will not cause this problem. Or if the physical memory is 1GB, setting MAXDSIZ
=(1024*1024*1024)
 will not cause the problem either.


Umm, the amount of physical memory has no bearing on how the virtual
address space for userland is laid out.  Do you know what virtual memory
is and how it works?  Your first e-mail seems to contradict this paragraph
as in your first e-mail you noted that the physical memory doesn't matter,
the solution was to not raise MAXDSIZ higher than 1GB and that is consistent
with running out of virtual address space due to MAXDSIZ reserving too much
address space for malloc().
  

   No quite clear on this. Does this mean that the MAXDSIZ cannot exceeed
   1GB regardless
   how many physical memory (say 16 GB) is installed? Then, this is
   definitiely a software bug.
   Then, somewhere the following checking is needed:
   #if (MAXDSIZ  1024 * 1024 * 1024)
   #undef   MAXDSIZ
   #define   MAXDSIZ   (1024 * 1024 * 1024)
   #endif
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: what causes error -- ELF interpreter /libexec/ld-elf.so.1 not found

2007-06-12 Thread John Baldwin
On Saturday 09 June 2007 08:53:18 pm Jin Guojun [VFFS] wrote:
 I believe that this is a memory sub-system bug somewhere because 
 anything equal to or below 1G
 
 options MAXDSIZ=(1024*1024*1024)
 
 will work regardless how many memory is installed in the system.
 I doubt this could be a hardware related issue although is memory size 
 related.
 
  Finally find cause but no idea why -- in kernel configuration, 
  following line causes the problem:
 
 options MAXDSIZ=(2097152U*1024)
 
  Can anyone explain why this can cause /libexec/ld-elf.so.1 not seen 
  for some program?

This is setting aside 2GB for malloc which leaves only 1GB for all of mmap and 
stack.  You probably don't have enough address space to map your binary.

-- 
John Baldwin
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: what causes error -- ELF interpreter /libexec/ld-elf.so.1 not found

2007-06-12 Thread Jin Guojun

   John Baldwin wrote:

On Saturday 09 June 2007 08:53:18 pm Jin Guojun [VFFS] wrote:
  

I believe that this is a memory sub-system bug somewhere because 
anything equal to or below 1G

options MAXDSIZ=(1024*1024*1024)

will work regardless how many memory is installed in the system.
I doubt this could be a hardware related issue although is memory size 
related.



Finally find cause but no idea why -- in kernel configuration, 
following line causes the problem:

   options MAXDSIZ=(2097152U*1024)

Can anyone explain why this can cause /libexec/ld-elf.so.1 not seen 
for some program?
  

This is setting aside 2GB for malloc which leaves only 1GB for all of mmap and 
stack.  You probably don't have enough address space to map your binary.
  

   This does not quite explain the problem.
   First of all, the MAXDSIZ is the maximum size for users to set their
   own datasize limit by 'limit'
   utility.  If user do not set a high limit for datasize, it should not
   be a problem.
   The second aspect also counters this assumption, for machines that
   have less than or equal to
   1 GB memory, and setting the MAXDISZ = the maximum memory size will
   not cause such problem.
   For example, if the physical memory size is 512 MB, and setting
   MAXDSIZ=(512*1024*1024)
   will not cause this problem. Or if the physical memory is 1GB, setting
   MAXDSIZ=(1024*1024*1024)
   will not cause the problem either.
   I will try to build a similar system on an AMD box with 2GB and more
   memory to see if this
   will be a problem.
   -Jin
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


what causes error -- ELF interpreter /libexec/ld-elf.so.1 not found

2007-06-09 Thread Jin Guojun [VFFS]
I have multiple FreeBSD 6.2 machines with different hardware, but one of 
them encountered

this strange error when running program wine.
I could not figure out what causes such error since /libexec/ld-elf.so.1 
absolutely exists, otherwise

no program will run.

It does not matter if the wine is pre-compiled in packages or I built it 
from ports.

All other machine do NOT have such problem.

I reinstalled this machine a few times, and it always does the same 
thing. However other programs

run well.
Would this is related to some particular hardware issue?
This one is ECS 848P-A7 motherboard with Intel P4 506+ CPU, plus 2 GB 
memory.
Other machines are HP AMD64 laptop, DELL Dual XEON, DELL Intel Laptop, 
and AMD XP 2100+,

and none of them ever had such problem.

129 /data: ldd `which wine`
/usr/local/bin/wine:
ELF interpreter /libexec/ld-elf.so.1 not found
/usr/local/bin/wine: signal 6

130 /data: ll /libexec/ld-elf.so.1
-r-xr-xr-x  1 root  wheel  158712 Jan 11 23:39 /libexec/ld-elf.so.1*

131 /data: wine
ELF interpreter /libexec/ld-elf.so.1 not found
Abort

132 /data: which wine
/usr/local/bin/wine

Does someone have an idea what is happening here?

-Jin

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: what causes error -- ELF interpreter /libexec/ld-elf.so.1 not found

2007-06-09 Thread Jin Guojun [VFFS]
Finally find cause but no idea why -- in kernel configuration, following 
line causes the problem:


   options MAXDSIZ=(2097152U*1024)

Can anyone explain why this can cause /libexec/ld-elf.so.1 not seen for 
some program?


Jin Guojun [VFFS] wrote:

I have multiple FreeBSD 6.2 machines with different hardware, but one 
of them encountered

this strange error when running program wine.
I could not figure out what causes such error since 
/libexec/ld-elf.so.1 absolutely exists, otherwise

no program will run.

It does not matter if the wine is pre-compiled in packages or I built 
it from ports.

All other machine do NOT have such problem.

I reinstalled this machine a few times, and it always does the same 
thing. However other programs

run well.
Would this is related to some particular hardware issue?
This one is ECS 848P-A7 motherboard with Intel P4 506+ CPU, plus 2 GB 
memory.
Other machines are HP AMD64 laptop, DELL Dual XEON, DELL Intel Laptop, 
and AMD XP 2100+,

and none of them ever had such problem.

129 /data: ldd `which wine`
/usr/local/bin/wine:
ELF interpreter /libexec/ld-elf.so.1 not found
/usr/local/bin/wine: signal 6

130 /data: ll /libexec/ld-elf.so.1
-r-xr-xr-x  1 root  wheel  158712 Jan 11 23:39 /libexec/ld-elf.so.1*

131 /data: wine
ELF interpreter /libexec/ld-elf.so.1 not found
Abort

132 /data: which wine
/usr/local/bin/wine

Does someone have an idea what is happening here?

-Jin



___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: what causes error -- ELF interpreter /libexec/ld-elf.so.1 not found

2007-06-09 Thread Jin Guojun [VFFS]
I believe that this is a memory sub-system bug somewhere because 
anything equal to or below 1G


   options MAXDSIZ=(1024*1024*1024)

will work regardless how many memory is installed in the system.
I doubt this could be a hardware related issue although is memory size 
related.


Finally find cause but no idea why -- in kernel configuration, 
following line causes the problem:


   options MAXDSIZ=(2097152U*1024)

Can anyone explain why this can cause /libexec/ld-elf.so.1 not seen 
for some program?


Jin Guojun [VFFS] wrote:

I have multiple FreeBSD 6.2 machines with different hardware, but one 
of them encountered

this strange error when running program wine.
I could not figure out what causes such error since 
/libexec/ld-elf.so.1 absolutely exists, otherwise

no program will run.

It does not matter if the wine is pre-compiled in packages or I built 
it from ports.

All other machine do NOT have such problem.

I reinstalled this machine a few times, and it always does the same 
thing. However other programs

run well.
Would this is related to some particular hardware issue?
This one is ECS 848P-A7 motherboard with Intel P4 506+ CPU, plus 2 GB 
memory.
Other machines are HP AMD64 laptop, DELL Dual XEON, DELL Intel 
Laptop, and AMD XP 2100+,

and none of them ever had such problem.

129 /data: ldd `which wine`
/usr/local/bin/wine:
ELF interpreter /libexec/ld-elf.so.1 not found
/usr/local/bin/wine: signal 6

130 /data: ll /libexec/ld-elf.so.1
-r-xr-xr-x  1 root  wheel  158712 Jan 11 23:39 /libexec/ld-elf.so.1*

131 /data: wine
ELF interpreter /libexec/ld-elf.so.1 not found
Abort

132 /data: which wine
/usr/local/bin/wine

Does someone have an idea what is happening here?

-Jin




--
 Jin Guojun --- v --- [EMAIL PROTECTED] ---
Distributed Systems Department  http://www.dsd.lbl.gov/~jin
Lawrence Berkeley National Laboratory,  Berkeley, CA 94720

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]