From owner-freebsd-hackers  Wed Dec 18 22:21:02 1996
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id WAA03191
          for hackers-outgoing; Wed, 18 Dec 1996 22:21:02 -0800 (PST)
Received: from rah.star-gate.com ([204.188.121.18])
          by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id WAA03174;
          Wed, 18 Dec 1996 22:20:58 -0800 (PST)
Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.7.6/8.7.3) with ESMTP id WAA08457; Wed, 18 Dec 1996 22:19:32 -0800 (PST)
Message-Id: <199612190619.WAA08457@rah.star-gate.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: Terry Lambert <terry@lambert.org>
cc: hackers@freebsd.org, multimedia@freebsd.org
Subject: Re: mmap problems? 
In-reply-to: Your message of "Wed, 18 Dec 1996 17:21:42 MST."
             <199612190021.RAA10646@phaeton.artisoft.com> 
Date: Wed, 18 Dec 1996 22:19:32 -0800
From: Amancio Hasty <hasty@rah.star-gate.com>
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>From The Desk Of Terry Lambert :
> > I am a little confuse . Why would "tv" work 3 or 5 times then fail to run
> > because the driver did not mmap properly the pages?
> 
> Because the VM space was exhausted because the cleanup-on-close never
> happened like it was supposed to...
> 
> And/or the VM space has to be contiguously allocated, and the necessary
> memory could not be allocated after a couple of runs because it was
> too fragmented.
> 
> You'll have to look carefully at the driver to see which is happening
> (if either is the correct reason).
> 

First, the driver used to work and it was recent change in the system
not in the driver which is causing the problem.

At attach, the meteor executes:

define RANGE_BOUNDARY  (1<<22)
static vm_offset_t
get_meteor_mem(int unit, unsigned size)
{
vm_offset_t     addr = 0;

        addr = vm_page_alloc_contig(size, 0x100000, 0xffffffff, 1<<24);
        if(addr == 0)
                addr = vm_page_alloc_contig(size, 0x100000, 0xffffffff,
                                                                PAGE_SIZE);
        if(addr == 0) {
                printf("meteor%d: Unable to allocate %d bytes of memory.\n",
                        unit, size);
        }

        return addr;
}

This call is executed once at boot time.

The mmap call in the driver is:
meteor_mmap(dev_t dev, int offset, int nprot)
{

        int     unit;
        meteor_reg_t *mtr;

        unit = UNIT(minor(dev));
        if (unit >= NMETEOR)            /* at this point could this happen? */
                return(-1);

        mtr = &(meteor[unit]);


        if(nprot & PROT_EXEC)
                return -1;

        if(offset >= mtr->alloc_pages * PAGE_SIZE)
                return -1;

        return i386_btop(vtophys(mtr->bigbuf) + offset);
}


------

The application mmaps a region from the driver :
       yuv_data = (uint8 *)mmap((caddr_t)0, frame_size,
                                PROT_READ,0, video, (off_t)0);


What this does is mmaps a region of memory which was allocated
by the driver at boot time. No further attempts is made by
the driver to allocate more memory.

So in our scenario , starting /killing the application a few times
the system fails to mmap properly all the requested pages. 
Mind you I am asking for the same number of pages so that
pretty much leaves the problem to either mmap or the VM system.


	Tnks
	Amancio