From owner-freebsd-bugs Tue Oct 31 7:30: 8 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 52BAC37B4C5 for ; Tue, 31 Oct 2000 07:30:03 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id HAA23005; Tue, 31 Oct 2000 07:30:03 -0800 (PST) (envelope-from gnats@FreeBSD.org) Date: Tue, 31 Oct 2000 07:30:03 -0800 (PST) Message-Id: <200010311530.HAA23005@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: William J Carpenter Subject: Re: i386/22441: pmap_growkernel() is not effective at kernel vm limit of 0xffc00000 Reply-To: William J Carpenter Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR i386/22441; it has been noted by GNATS. From: William J Carpenter To: dg@root.com Cc: freebsd-gnats-submit@FreeBSD.ORG Subject: Re: i386/22441: pmap_growkernel() is not effective at kernel vm limit of 0xffc00000 Date: Tue, 31 Oct 2000 10:20:20 -0500 (EST) cc: freebsd-gnats-submit@FreeBSD.ORG From: David Greenman Reply-To: dg@root.com Date: Tue, 31 Oct 2000 06:23:19 -0800 Sender: dg@implode.root.com >When called with a kernel vm limit of 0xffc00000, pamp_growkernel() >does not set-up the page mapping hardware because of an overflow. > >In this line: > > addr = (addr + PAGE_SIZE * NPTEPG) & ~(PAGE_SIZE * NPTEPG - 1); > ( Line 1403 in $FreeBSD: src/sys/i386/i386/pmap.c,v 1.250.2.5 2000/08/05 00:39:08 peter Exp $) > >addr + PAGE_SIZE * NPTEPG overflows to zero when addr is 0xffc00000. I might not be understanding what you're doing exactly, I am not sure that what I am doing is strictly necessary, but I can successfully allocate kernel vm this way in BSDI. but I should point out that the alternate page table map (APTmap) starts at 0xffc00000, so I don't see how you could ever use that area of virtual memory without serious problems. What am I missing? That's good to know. The problem is that 0xffc00000 is passed as a limit to pmap_growkernel(). I am not using 0xffc00000, I am using memory up to 0xffc00000 which is the advertised limit to kernel vm. (kernel_map->header.end) (kgdb) print /x * kernel_map $221 = {header = {prev = 0xc02c1d60, next = 0xc02c1f70, start = 0xbfeff000, end = 0xffc00000, avail_ssize = 0x0, object = {vm_object = 0x0, sub_map = 0x0}, offset = 0x0, eflags = 0x0, protection = 0x0, max_protection = 0x0, inheritance = 0x0, wired_count = 0x0, lastr = 0x0}, lock = {lk_interlock = {lock_data = 0x0}, lk_flags = 0x1000000, lk_sharecount = 0x0, lk_waitcount = 0x0, lk_exclusivecount = 0x0, lk_prio = 0x4, lk_wmesg = 0xc0277da0, lk_timo = 0x0, lk_lockholder = 0xffffffff}, nentries = 0x9, size = 0x1e531000, system_map = 0x1, hint = 0xc02c1d60, timestamp = 0x21, first_free = 0xc02c1d00, pmap = 0xc02cf8c0} Pmap_growkernel()'s job is to set-up the physical page mappings to cover the increased kernel vm. In order to do this on the i386 architecture, a page map directory entry must be made for every 4mbytes of memory. The kernel vm layer rounds vm up to a page boundary. The physical map layer must round-up a 4mbyte boundary because of the two level i386 page mapping hierarchy. If the vm layer kernel memory limit falls on a page boundary, but not on a page directory boundary, say 0xffb01000, then as far as physical map layer is concerned, a page directory entry must be created to cover vm from 0xffb00000 to 0xffbfffff. If the vm layer limit falls on 0xffb00000, this means that the kernel requested vm in the range 0xffaff000 to 0xffafffff. The vm layer rounds this address up to 0xffb00000 and declares that this is the limit for pmap_growkernel(). In the case where the limit is 0xffb00000, pmap_growkernel actually makes a page directory entry for adresses >= 0xffb00000 -- a harmless sort of overflow which merely sucks up an extra page of memory. In the case where the kernel vm grows to the range of [ 0xffbff001, 0xffc00000-1 ], (the page below 0xffc00000, in this case, kernel vm requested explicitly by me), pmap_growkernel() overflows by rounding 0xffc0000 up to the next 4m boundary which on 32-bit machines is 0. I hope this helps explain what I think is a problem. Bill -- Bill Carpenter carp@world.std.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message