From owner-freebsd-current Fri Jan 12 16:27:44 2001 Delivered-To: freebsd-current@freebsd.org Received: from email_server.midstream.com (unknown [63.113.115.195]) by hub.freebsd.org (Postfix) with ESMTP id 8F5C737B402 for ; Fri, 12 Jan 2001 16:27:18 -0800 (PST) Received: by EMAIL_SERVER with Internet Mail Service (5.5.2650.21) id ; Fri, 12 Jan 2001 16:29:37 -0800 Message-ID: <31E4B6337A4FD411BD45000102472E0C05E72A@EMAIL_SERVER> From: Jeff Roberson To: 'Bruce Evans' Cc: "'freebsd-current@freebsd.org'" Subject: RE: Broken mmap in current? Date: Fri, 12 Jan 2001 16:29:29 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C07CF7.E8E735A0" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C07CF7.E8E735A0 Content-Type: text/plain; charset="iso-8859-1" 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! Jeff -----Original Message----- From: Bruce Evans [mailto:bde@zeta.org.au] Sent: Thursday, January 11, 2001 8:52 PM To: Jeff Roberson Cc: 'freebsd-current@freebsd.org' 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). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message ------_=_NextPart_001_01C07CF7.E8E735A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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!
Jeff

-----Original Message-----
From: Bruce Evans [mailto:bde@zeta.org.au]
Sent: Thursday, January 11, 2001 8:52 PM
To: Jeff Roberson
Cc: 'freebsd-current@freebsd.org'
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).

Bruce



To Unsubscribe: send mail to = majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the = body of the message

------_=_NextPart_001_01C07CF7.E8E735A0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message