Re: bus_dmamem_alloc confusion
:Exactly
:
: fdM = open("/dev/mem", O_RDWR);
: ...
: virt = mmap(0, mem.length,
: PROT_READ | PROT_WRITE,
: MAP_PRIVATE | MAP_ANON,
: fdM,
: (off_t)mem.baddr);
:
: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.
-Matt
Matthew Dillon
<dillon@backplane.com>
:Let me know if there are other useful items I can dump out or other
:places to look.
:
:--
:Chuck Tuffli
:Agilent Technologies
:
討論串 (同標題文章)
完整討論串 (本文為第 7 之 9 篇)：