From owner-freebsd-emulation@FreeBSD.ORG Fri Apr 30 07:42:41 2004 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B324316A4CE for ; Fri, 30 Apr 2004 07:42:41 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4EAC443D41 for ; Fri, 30 Apr 2004 07:42:41 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.10/8.12.10) with ESMTP id i3UEgexZ003295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Apr 2004 10:42:40 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id i3UEgXOQ089962; Fri, 30 Apr 2004 10:42:33 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16530.26073.555667.482789@grasshopper.cs.duke.edu> Date: Fri, 30 Apr 2004 10:42:33 -0400 (EDT) To: Marcel Moolenaar In-Reply-To: <20040430000437.GB39055@ns1.xcllnt.net> References: <16528.65255.326986.106534@grasshopper.cs.duke.edu> <20040430000437.GB39055@ns1.xcllnt.net> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: freebsd-emulation@freebsd.org Subject: Re: user mode linux? X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2004 14:42:41 -0000 Marcel Moolenaar writes: > > Two things you might wan to look into: > 1. Is there an issue with mmap(2)'ing sparse files? > 2. Are limits being hit (most notably RLIMIT_DATA)? > I think I've "figured it out" to the extent I can. The mmap is done like this: linux_mmap_common(0, 1785856, 3, 0x00000801, 3, 0x0) The failure happens due to this check in vm_map_findspace(): if (start > map->max_offset) When I print things out here, I see: start = 0xc0001000, map->min_offset = 0x0, map->max_offset = 0xbfc00000 This "start" is the addr that was chosen in mmap() for non-MAP_FIXED mappings: if (addr == 0 || (addr >= round_page((vm_offset_t)vms->vm_taddr) && addr < round_page((vm_offset_t)vms->vm_daddr + lim_max(td->td_proc, RLIMIT_DATA)))) addr = round_page((vm_offset_t)vms->vm_daddr + lim_max(td->td_proc, RLIMIT_DATA)); I can work around this with a hack in linux_mmap_common() to set the address to 4K so that this code never runs, but I'd really like to understand what's happening... Hmm.. Another work around is to break into ddb and *reduce* maxdsize from the default 512MB to 256MB: db> e maxdsiz maxdsiz: 20000000 db> w maxdsiz 10000000 Thanks, Drew Index: i386/linux/linux_machdep.c =================================================================== RCS file: /home/ncvs/src/sys/i386/linux/linux_machdep.c,v retrieving revision 1.41 diff -u -r1.41 linux_machdep.c --- i386/linux/linux_machdep.c 4 Feb 2004 21:52:54 -0000 1.41 +++ i386/linux/linux_machdep.c 30 Apr 2004 14:19:21 -0000 @@ -539,6 +539,9 @@ (void *)bsd_args.addr, bsd_args.len, bsd_args.prot, bsd_args.flags, bsd_args.fd, (int)bsd_args.pos); #endif + if (((bsd_args.flags & MAP_FIXED) == 0) && (bsd_args.addr == 0)) + bsd_args.addr = 4096; + error = mmap(td, &bsd_args); #ifdef DEBUG if (ldebug(mmap))