trouble mmapping dma buffer

trouble mmapping dma buffer

[Steve Rossi]

I wrote a driver, which used to work under the stable 2.4.16 kernel, but
since I've moved up to the 2.4.19-pre7 development kernel it has stopped
working. The driver basically allocates a dma buffer (64K) using
consistent_alloc and it marks all of the pages in the kernel's mapping
of this buffer reserved (calling mem_map_reserve for each page). A user
space application calls mmap on the driver to get direct access to that
64K DMA buffer. The mmap routine in the driver sets VM_RESERVED in
vma->vm_flags then uses remap_page_range to map the physical address of
the DMA buffer to the user space virtual memory area, one page at a
time. It also marks each page _PAGE_NO_CACHE and _PAGE_GUARDED in the
user space mapping.
This all worked just fine under 2.4.16, but now under 2.4.19-pre7 when I
run the application that mmaps the device I get the following:

swap_dup: Bad swap file entry 00000004

repeated 16 times (note - that's how many pages are in my dma buffer)
followed by:

swap_free: Bad swap file entry 00000004

also repeated 16 times.
When the application exists and calls munmap, I get
swap_free: Bad swap file entry 00000004
another 16 times.
I'm running on an 8xx systems with 32MB of RAM. I have no swap space.
The DMA buffer typically gets allocated around physical address
0x19A0000, up near the top of the memory. I'm guessing that maybe the
kernel thinks that the mmaped pages are swapped out?? But why? Has
anything changed between 2.4.16 and 2.4.19-pre7 that could account for
this. Is there a problem with using remap_page_range to map RAM? I would
appreciate any help!

Thanks!
Steve

--
-------------------------------------------------------
Steven K. Rossi                     srossi@labs.mot.com
Senior Staff Engineer
Multimedia Communications Research Laboratory
Motorola Labs
-------------------------------------------------------


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: trouble mmapping dma buffer

[Steve Rossi]

Found the problem ... consistent_alloc has changed between 2.4.16 and 2.4.19.
In 2.4.19 it allocates a new virtual memory area and returns addresses in the
new virtual area. remap_page_range can't handle this properly - actually to my
understanding, remap_pte_range doesn't handle it because it does
virt_to_page(__va(phys_addr)) which doesn't return the correct virtual address
in the new virtual memory area. Is this intentional - that consistent_alloc
returns addresses that can't be mmapped? Is there a better way of allocating a
DMA buffer in RAM and remapping it to user space? For now I'm using an
allocation routine based on the 2.4.16 version of consistent_alloc, and that
works.

Steve


Steve Rossi wrote:

> I wrote a driver, which used to work under the stable 2.4.16 kernel, but
> since I've moved up to the 2.4.19-pre7 development kernel it has stopped
> working. The driver basically allocates a dma buffer (64K) using
> consistent_alloc and it marks all of the pages in the kernel's mapping
> of this buffer reserved (calling mem_map_reserve for each page). A user
> space application calls mmap on the driver to get direct access to that
> 64K DMA buffer. The mmap routine in the driver sets VM_RESERVED in
> vma->vm_flags then uses remap_page_range to map the physical address of
> the DMA buffer to the user space virtual memory area, one page at a
> time. It also marks each page _PAGE_NO_CACHE and _PAGE_GUARDED in the
> user space mapping.
> This all worked just fine under 2.4.16, but now under 2.4.19-pre7 when I
> run the application that mmaps the device I get the following:
>
> swap_dup: Bad swap file entry 00000004
>
> repeated 16 times (note - that's how many pages are in my dma buffer)
> followed by:
>
> swap_free: Bad swap file entry 00000004
>
> also repeated 16 times.
> When the application exists and calls munmap, I get
> swap_free: Bad swap file entry 00000004
> another 16 times.
> I'm running on an 8xx systems with 32MB of RAM. I have no swap space.
> The DMA buffer typically gets allocated around physical address
> 0x19A0000, up near the top of the memory. I'm guessing that maybe the
> kernel thinks that the mmaped pages are swapped out?? But why? Has
> anything changed between 2.4.16 and 2.4.19-pre7 that could account for
> this. Is there a problem with using remap_page_range to map RAM? I would
> appreciate any help!
>
> Thanks!
> Steve
>
> --
> -------------------------------------------------------
> Steven K. Rossi                     srossi@labs.mot.com
> Senior Staff Engineer
> Multimedia Communications Research Laboratory
> Motorola Labs
> -------------------------------------------------------
>

--
-------------------------------------------------------
Steven K. Rossi                     srossi@labs.mot.com
Senior Staff Engineer
Multimedia Communications Research Laboratory
Motorola Labs
-------------------------------------------------------


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: trouble mmapping dma buffer

[David Gibson]

On Tue, Jun 18, 2002 at 12:00:42PM -0500, Steve Rossi wrote:
>
> Found the problem ... consistent_alloc has changed between 2.4.16 and 2.4.19.
> In 2.4.19 it allocates a new virtual memory area and returns addresses in the
> new virtual area. remap_page_range can't handle this properly - actually to my
> understanding, remap_pte_range doesn't handle it because it does
> virt_to_page(__va(phys_addr)) which doesn't return the correct virtual address
> in the new virtual memory area. Is this intentional - that consistent_alloc
> returns addresses that can't be mmapped? Is there a better way of allocating a
> DMA buffer in RAM and remapping it to user space? For now I'm using an
> allocation routine based on the 2.4.16 version of consistent_alloc, and that
> works.

You can remap it into user space, it's just that you can't get to the
(page *) with virt_to_page() on the virtual address returned by
consistent_alloc() (virt_to_page() is only reliable on kernel lowmem
addresses).

You can use phys_to_page() on the dma handle returned by
consistent_alloc, though.

> Steve Rossi wrote:
>
> > I wrote a driver, which used to work under the stable 2.4.16 kernel, but
> > since I've moved up to the 2.4.19-pre7 development kernel it has stopped
> > working. The driver basically allocates a dma buffer (64K) using
> > consistent_alloc and it marks all of the pages in the kernel's mapping
> > of this buffer reserved (calling mem_map_reserve for each page). A user
> > space application calls mmap on the driver to get direct access to that
> > 64K DMA buffer. The mmap routine in the driver sets VM_RESERVED in
> > vma->vm_flags then uses remap_page_range to map the physical address of
> > the DMA buffer to the user space virtual memory area, one page at a
> > time. It also marks each page _PAGE_NO_CACHE and _PAGE_GUARDED in the
> > user space mapping.
> > This all worked just fine under 2.4.16, but now under 2.4.19-pre7 when I
> > run the application that mmaps the device I get the following:
> >
> > swap_dup: Bad swap file entry 00000004
> >
> > repeated 16 times (note - that's how many pages are in my dma buffer)
> > followed by:
> >
> > swap_free: Bad swap file entry 00000004
> >
> > also repeated 16 times.
> > When the application exists and calls munmap, I get
> > swap_free: Bad swap file entry 00000004
> > another 16 times.
> > I'm running on an 8xx systems with 32MB of RAM. I have no swap space.
> > The DMA buffer typically gets allocated around physical address
> > 0x19A0000, up near the top of the memory. I'm guessing that maybe the
> > kernel thinks that the mmaped pages are swapped out?? But why? Has
> > anything changed between 2.4.16 and 2.4.19-pre7 that could account for
> > this. Is there a problem with using remap_page_range to map RAM? I would
> > appreciate any help!
> >
> > Thanks!
> > Steve
> >
> >
>

--
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.  -- H.L. Mencken
http://www.ozlabs.org/people/dgibson

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/