Yes. Things like svgalib and XFree86 use this to access video memory.
> I try to mmap() a page into a physical address (0x100000). In one run, I
> get a virtual address back 0x8060000 (which sounds fine), which translates
> into physical address 0x3fe3000 (i.e. not the one I asked for). When I
> dereference the pointer to write to it, the value never gets into 0x100000.
How do you know it is physical address 0x3fe3000? Have you checked the
pte?
> What's curious about this, of course (aside from getting the wrong
> physical address), is that the address I do get back (physical address:
> 0x3fe3000) is in the region of the initrd ram disk.
>
> Since the file /dev/mem is on this RAM disk, it almost makes sense, but to
> double check, the file is a device file and not a regular file:
>
> [svlinux1.intel.com]-> bias_00000001 22> ls -l /mnt/ram/dev/mem
> 0 crw-r----- 1 root kmem 1, 1 May 5 1998 /mnt/ram/dev/mem
It's true, if it were a file, the pte would point into the file.
> Any clues on this one? I am using a fairly unusual kernel (2.1.126 + lots
> of hacks, and with almost no hardware support compiled in). None of our
> kernel changes affect mmap stuff (just initialization and scheduler).
What platform? /dev/mem might not behave the same on some
architectures. And do your changes affect /dev/mem?
> The method of translating the virtual address to physical address is an
> internal product. I would like to find a second way to do this to verify
> that this is correct. Any suggestions?
If you're trying to map any old memory and get its physical address, the
best way is undoubtedly write a device driver to kmalloc() memory, have
the driver return the physical address through an ioctl(), and support
mmap() for that device. The driver's mmap function will set up the page
mappings; see the sound driver for an example.
If you're trying to access a memory mapped device, mmap() on /dev/mem is
what everyone else does.
-- Jamie
-
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.tux.org/lkml/