From owner-freebsd-hardware@FreeBSD.ORG Wed Jun 13 22:32:48 2007 Return-Path: X-Original-To: freebsd-hardware@freebsd.org Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7CC0716A46B for ; Wed, 13 Jun 2007 22:32:48 +0000 (UTC) (envelope-from jin@george.lbl.gov) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by mx1.freebsd.org (Postfix) with SMTP id 66FB713C45D for ; Wed, 13 Jun 2007 22:32:48 +0000 (UTC) (envelope-from jin@george.lbl.gov) Received: (qmail 18018 invoked from network); 13 Jun 2007 22:32:48 -0000 Received: from unknown (HELO ?192.168.1.201?) (jinmtb@sbcglobal.net@67.111.218.237 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 13 Jun 2007 22:32:47 -0000 X-YMail-OSG: U5VosxsVM1njcv2M9Z49yCH5X9_W8Bb2FvbTCI1aDhwBRuwYt.xEaWErt0m4qWdOV3oytRFtsA-- Message-ID: <4670708A.5030805@george.lbl.gov> Date: Wed, 13 Jun 2007 15:32:42 -0700 From: Jin Guojun User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20061027 X-Accept-Language: zh, zh-CN, en To: John Baldwin References: <466B2B9F.5010308@lbl.gov> <200706121527.04274.jhb@freebsd.org> <466F4642.8070001@george.lbl.gov> <200706131001.25840.jhb@freebsd.org> In-Reply-To: <200706131001.25840.jhb@freebsd.org> Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: questions@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: what causes error -- ELF interpreter /libexec/ld-elf.so.1 not found X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 22:32:48 -0000 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