Title: RE: Broken mmap in current?

I think I spoke too soon..  I saw thousands of calls to mmap and assumed it was the thousands of read/writes that I was doing.  It's actually for the thousands (8192) of pages that I'm mapping in.  Oddly enough though there are only 3272 calls to my mmap routine each time I run the program.  I will investigate further.

I did find a bug in mlock() and munlock().  I tried mlock()ing after I mmaped, which I later realized was bogus since the pages are always resident as they exist on the bus.  Anyway the kernel faults in vm_page_unwire when I munlock.  I will investigate further and post a pr though.

Thanks for your help!

-----Original Message-----
From: Bruce Evans [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 11, 2001 8:52 PM
To: Jeff Roberson
Subject: Re: Broken mmap in current?

On Thu, 11 Jan 2001, Jeff Roberson wrote:

> I have written a character device driver for a proprietary PCI device that
> has a large sum of mapable memory.  The character device supports mmap()
> which I use to export the memory into a user process.  I have no problems
> accessing the memory on this device, but I notice that my mmap routine is
> called for every access!  Is this a problem with current, or a problem with
> my mmap?

Maybe both.  The device mmap routine is called mainly by the mmap
syscall for every page to be mmapped.  It is also called by
dev_pager_getpages() for some pagefaults, but I think this rarely happens.

> I use bus_alloc_resource and then rman_get_start to get the physical address
> in my attach, and then the mmap just returns atop(physical address).  I
> assumed this is correct since I have verified with a logical analyzer that I
> am indeed writing to the memory on the device.

This is correct.  I looked at some examples.  Many drivers get this
wrong by using i386_btop(), alpha_btop(), etc.  (AFAIK, atop() is
for addresses which are what we are converting here, btop() is for
(byte) offsets, and the machine-dependent prefixes are a vestige of
page clustering code that mostly went away 7 years ago.

> Also, I noticed that the
> device's mmap interface does not provide any way to limit the size of the
> block being mapped?  Can I specify the length of the region?

The length is implicitly PAGE_SIZE.  The device mmap function is called
for each page to be mapped.  It must verify that the memory from offset
to (offset + PAGE_SIZE - 1) belongs to the device and can be accessed
with the given protection, and do any device-specific things necessary to
enable this memory.  This scheme can't support bank-switched device
memory very well, if at all.

pcvvt_mmap() in the pcvt driver is the simplest example of this.
agp_mmap() is a more up to date example with the same old bug that the
vga drivers used to have (off by 1 (page) error checking the offset).


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to