I asked a question about this a while back, but I have a bit more
information now, so I'm updating my questions. I'm running 2.1.110 SMP
(although I've tried this w/o SMP and it looks the same). The
bigphysarea patch has been applied (I found bigphysarea-2.1.85 and
applied that, seems to work).
Anyway, I have a device driver for a video capture card that works by
allocating a buffer for the capture card to DMA into. The user program
then uses mmap on the device file to get at this buffer, and ioctl to
set up an interrupt such that the user is interrupted on each new frame.
Most everything works (and everything did work on 2.0.34 non-SMP),
except that the memory mapping is acting strange, at least to my
understanding. I use printk to see what the address of the buffer is in
the driver, and printf to see what address the device file is mapped to
in memory. Then, I look in /proc/<PID>/maps, and there is an entry that
says that the correct mapping is there. The problem is that when I read
from the buffer in the user program, I get each byte as being 0xFF.
When I print out values from the buffer on the device driver side of
things, I get sane values. At least something that looks like it could
be 16 YUV values, and most definitely _not_ 0xFFFF.
The mmap code is almost identical to that for the /dev/mem driver,
except that vma->vm_offset is changed to be the address of the buffer
that I want to mmap. To try to isolate the bigphysarea patch, instead
of mmaping the large buffer, I just mmaped a small kmalloced buffer and
I get the same problem. Then, for kicks, I tried leaving vma->vm_offset
at 0x0, and that seemed to work, at least I got random looking values,
not just 0xFF.
Does anybody have and idea what's up here? Is this some kind of fancy
security feature I don't know about to keep people from reading memory
they shouldn't or am I completely off in my understanding of the address
space (quite possible), or something else? Thanks very much for the
help,
-Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html