Problem with DMA buffer (in 2.2.15)

Problem with DMA buffer (in 2.2.15)

Post by Christoph Bauman » Fri, 23 Feb 2001 02:12:34



Hello!

I have the following problem.
A user process wants to talk to a PCI board via DMA. The first step I did was
to resolv the physical addresses of the data in user space. This works fine
when writing to the device. But when reading the buffer isn't allocated
and the physical addresses are resolved to zero. I fixed this with initializing
the buffer. My question is: Is there a faster method to get the kernel to
map all the virtual addresses at once and not each by each? This would
increase the performance enormously (from 33MB/s to [hopefully] 100MB/s).

Christoph

--
**********************************************************
* Christoph Baumann                                      *
* Kirchhoff-Institut fr Physik - Uni Heidelberg         *

* Phone: ++49-6221-54-4329                               *
**********************************************************

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Problem with DMA buffer (in 2.2.15)

Post by Christoph Bauman » Sat, 24 Feb 2001 01:24:58


I messed up my subscription to this list yesterday so any answer to my question
didn't reach me (I looked through the archive up to 20:50 yesterday).
Now as I read my question again I decided to add some more details.

Quote:>But when reading the buffer isn't allocated

This is of course rubbish. I meant the buffer isn't initialized.

Some more details about what I'm doing:
I have a PCI board with 1M of RAM and a PLX9080 on it (and some more chips
which don't matter here). So far I have established normal communication with
the board (to program the PLX etc.). Now I want to write larger junks of data
to the RAM. So I startet to resolve the physical addresses of the user space
data to generate a chain list. Everything works fine for writing to the RAM.
The problem is reading. If I allocate a new buffer for reading back it isn't
of course not yet mapped to physical memory. The "quick and dirty"(tm) hack
was writing a zero to each buffer element to get it mapped. The better version
is to do this in steps of PAGE_SIZE. What I'm looking for is a kernel routine
to force the mapping of previous unmapped pages. Browsing through the source
in mm/ I found make_pages_present(). Could this be the solution? I hadn't the
time to try it out yet.

Christoph

--
**********************************************************
* Christoph Baumann                                      *
* Kirchhoff-Institut fr Physik - Uni Heidelberg         *

* Phone: ++49-6221-54-4329                               *
**********************************************************

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Problem with DMA buffer (in 2.2.15)

Post by Norbert Roo » Sat, 24 Feb 2001 01:38:53



> is to do this in steps of PAGE_SIZE. What I'm looking for is a kernel routine
> to force the mapping of previous unmapped pages. Browsing through the source
> in mm/ I found make_pages_present(). Could this be the solution? I hadn't the

Have you already looked at mlock(2)?

Norbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Problem with DMA buffer (in 2.2.15)

Post by Christoph Bauman » Sat, 24 Feb 2001 02:20:42




> > is to do this in steps of PAGE_SIZE. What I'm looking for is a kernel routine
> > to force the mapping of previous unmapped pages. Browsing through the source
> > in mm/ I found make_pages_present(). Could this be the solution? I hadn't the

> Have you already looked at mlock(2)?

Well I would have done all this (mlock, alloc buffer in kernel space and map it to user space etc.). But the critical issue is that all should be code compatible to Win (ducking away...). The API under Win allows chain DMA from user space
so the program which was initially developed under Win uses this feature. My
module needs to jump in to support this. Another problem is that the buffer
is often reallocated.

Christoph

--
**********************************************************
* Christoph Baumann                                      *
* Kirchhoff-Institut fr Physik - Uni Heidelberg         *

* Phone: ++49-6221-54-4329                               *
**********************************************************

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

1. Feedback on 2.2.15 (wasRe: Kernel Stable: 2.2.15pre4 )

I've been trying the 2.2.15 prereleases, and so far they seem great.
2.2.15 pre 4 (subjectively speaking) made my system much zippier
than 2.2.13/4 and 2.2.15 pre 5 which I built last night, feels
faster still (and apparently has some rather neat debug code to
trap bad application memory use/kernel bugs).

So overall I'm very pleased. Many thanks to Alan and the guys who've
been working on the VM stuff. It feels great for me.

BTW I'm running this on Mandrake 6.1, Cyrix 6x86 MX 300, 64MB RAM.

Like I say, 2.2.15 feels like it's shaping up to be the best 2.2 kernel
yet by a significant margin (to me at least!)
Mike



Sent via Deja.com http://www.deja.com/
Before you buy.

2. Newbie... ping works Netscape doesn't

3. USB problems compiling 2.2.15pre19

4. File Time Via Shell

5. ICQ problems with IP Masq Debian 2.2.15

6. Mounting Network Drives

7. pctel 'linmodem' driver with 2.2.15 problem

8. ES1938 config problem with RedHat6.0

9. G4 - Kernel 2.2.15pre7 - USB problems :-(

10. Kernel 2.2.15 Problem

11. Problems with Netscape 4.7 and 2.2.15

12. ISA NE2000 Clone + 2.2.15 SMP Kernel Problems

13. pctel 'linmodem' driver with 2.2.15 problem