From owner-freebsd-hackers Thu Oct 26 16:12:48 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA03473 for hackers-outgoing; Thu, 26 Oct 1995 16:12:48 -0700 Received: from plains.nodak.edu (89@plains.NoDak.edu [134.129.111.64]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA03466 for ; Thu, 26 Oct 1995 16:12:45 -0700 Received: (from tinguely@localhost) by plains.nodak.edu (8.6.11/8.6.10) id SAA01148; Thu, 26 Oct 1995 18:12:26 -0500 Date: Thu, 26 Oct 1995 18:12:26 -0500 From: Mark Tinguely Message-Id: <199510262312.SAA01148@plains.nodak.edu> To: dufault@hda.com, hackers@freebsd.org Subject: Re: Physically contig memory in user process Content-Length: 636 Sender: owner-hackers@freebsd.org Precedence: bulk if you implement contigous page allocation using vm_page_alloc_contig, start above the 1 MB mark, because I found writing the meteor capture driver that if you allocate a good size chunk that starts below the 1 MB mark it could panic the system when you free the chunk. my video buffer was large enough to do it every time. starting above the 1MB mark works correctly every time. I figure it had to do with the hole between 640KB and 1MB, but that is not backed with real evidence. why not allocate the buffers as part of the device's driver and mmap them into user space instead of allocating them into users space directly? --mark.