Re: bus_dmamem_alloc confusion

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

: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@xxxxxxxxxxxxx>

:Let me know if there are other useful items I can dump out or other
:places to look.
:
:-- 
:Chuck Tuffli
:Agilent Technologies
: