From owner-freebsd-hackers  Tue Aug 27 10:42:41 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id KAA17140
          for hackers-outgoing; Tue, 27 Aug 1996 10:42:41 -0700 (PDT)
Received: from gateway.zeus.leitch.com (gateway.zeus.leitch.com [205.210.38.6])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA17133
          for <FreeBSD-hackers@freebsd.org>; Tue, 27 Aug 1996 10:42:38 -0700 (PDT)
Received: from tap.zeus.leitch.com (0@tap.zeus.leitch.com [204.187.60.10]) by gateway.zeus.leitch.com (8.6.12/8.6.9) with ESMTP id NAA00567; Tue, 27 Aug 1996 13:43:22 -0400
Received: from ale.zeus.leitch.com (0@ale.zeus.leitch.com [204.187.61.65]) by tap.zeus.leitch.com (8.6.12/8.6.6) with ESMTP id NAA02750; Tue, 27 Aug 1996 13:42:54 -0400
From: Dave Chapeskie <dchapes@zeus.leitch.com>
Received: (dchapes@localhost) by ale.zeus.leitch.com (8.6.12/8.6.9) id NAA14487; Tue, 27 Aug 1996 13:42:54 -0400
Message-Id: <199608271742.NAA14487@ale.zeus.leitch.com>
Subject: Re: kernel vm_page_alloc_contig() can indirectly cause kernel page faults
To: tinguely@plains.nodak.edu (Mark Tinguely)
Date: Tue, 27 Aug 1996 13:42:54 -0400 (EDT)
Cc: FreeBSD-hackers@freebsd.org
In-Reply-To: <199608250327.WAA26323@plains.nodak.edu> from Mark Tinguely at "Aug 24, 96 10:27:02 pm"
X-Mailer: ELM [version 2.4ME+ PL19 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Mark Tinguely wrote:
> I reported this panic last summer when I started writing the Meteor driver.
> THe work around I used wast to start the allocation starting at the
> first Meg mark, at that time I speculated it was treating the low memory
> and the first meg as being contiguous even though there is a memory
> hole between them. Starting contiguous allocation at/after the first
> meg never caused anymore panics, so I left it at that.
> 
> --mark.

    Interesting.  It was from your driver that I found the
vm_page_alloc_contig() call and I use the same low and high range
as you.

    I have found one strange problem with my fix however.  At one
point the contiguous memory gets mmaped into user space (via the
devices d_mmap hook), if the process forks after this point the
pmap gets screwed up once the child exits.  I can walk through the
kernel_map and find the virtual address range still wired and
pointing to the same vm_page's but vtophys() and pmap_kextract()
both give 0.  Does anyone have any ideas of how to track this one down?

-- 
Dave Chapeskie, x2358