dillon at apollo.backplane.com
Thu Oct 21 21:52:35 PDT 2004
: fdM = open("/dev/mem", O_RDWR);
: virt = mmap(0, mem.length,
: PROT_READ | PROT_WRITE,
: MAP_PRIVATE | MAP_ANON,
:where mem.baddr is the physical address passed back by the kernel.
MAP_PRIVATE? If you intend to write to the memory you definitely
do not want a private mapping, that will do a copy-on-write for any
modifications you make via the map and not actually modify the physical
memory you mapped. Use MAP_SHARED.
MAP_ANON? That's a contradiction in terms. This isn't anonymous
memory. Don't use MAP_ANON.
:Thanks! I put a bzip2 tar at http://www.tuffli.net/pmem_prob.tbz that
:includes the driver (pdrv.[ch]) and its Makefile as well as a user
:space program that exercises it (ptest.c). None of the code relies on
:any particular hardware except for some unclaimed PCI device.
:I traced through some of the vm code and see where the phys_avail
:regions get converted into the vm_page_array (vm_page_startup()) which
:is what contigmalloc ultimately uses. Nothing looked obviously weird,
:but then again, I'm not totally sure what I'm looking for. One thing I
:didn't understand were the two regions (at least on i386) described by
:phys_avail (0x1000-0x9efff for the first and 0x4ca000-0x7eb7fff for
:the second). The system this is on has 64MB of memory (0x9f000?), but
:I don't understand what the second region might represent.
:This time, vm_contig_pg_alloc() ends up allocating phys_addr 0x16000
:with the vm_page_t looking like
That doesn't look right, unless you actually have 128MB of ram instead
of 64MB of ram. Then it looks reasonable.
The first section must be some bios-recovered ram. Now that I think
about it, it makes sense. In that case the contig allocation can
legally return 0x16000.
<dillon at xxxxxxxxxxxxx>
:Let me know if there are other useful items I can dump out or other
:places to look.
More information about the Kernel