Date: Tue, 28 Oct 1997 01:37:44 -0800 From: "Guillermo A. Loyola" <gmo@epigram.com> To: Christoph Kukulies <kuku@gilberto.physik.RWTH-Aachen.DE> Cc: freebsd-hackers@freefall.FreeBSD.org Subject: Re: mmap/mlock problem Message-ID: <3455B267.FBC7DD67@epigram.com> References: <199710271231.NAA03303@gil.physik.rwth-aachen.de> <199710271303.IAA24466@hda.hda.com> <19971027151139.61831@gil.physik.rwth-aachen.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Christoph Kukulies wrote:
> The ISA mapped memory is a dual ported RAM which is
> controlled by the on board CPU on one end and the,
> user process on the other end. Writing something
> into the ISA memory should not result in reading
> the same back from it. But the fact of the matter is
> that I read back what I'v written into it and this
> seems to me as if the memory is cached.
>
> I tried a mlock call on the mmapped region but this
> seems to fail in the user process.
As pointed by Peter, it is not locking that you need. What is needed
is a way to map the memory un-cached. The bad news is that there does
not seem to be any interface to do that at user level.
Worse yet, the interface for drivers to do it pmap_mapdev()
claims to make the mapping non-cached in the comment, but the code
does not seem to be doing it. The non-cached bits are defined in
pmap.h:
i386/include/pmap.h:75:#define PG_N (PG_NC_PWT|PG_NC_PCD) /* Non-cacheable */
but are only used in machdep.c when probing memory.
Questions for FreeBSD hackers:
1) Shouldn't the line that sets the ptes in pmap_mapdev read:
*pte = pa | PG_RW | PG_N | PG_V;
instead of
*pte = pa | PG_RW | PG_V;
?
2) WOuld it be reasonalbe to add a new flag to mmap to allow
specification of uncached mappings?
and on a semi-related topic:
3) It seems that the offset in the mmap system call, which is an off_t
(i.e. long long) is re-cast into an unsigned int for devices in
dev_pager_alloc(), before calling the device's mmap routine. I guess
devices are not expected to have more than 32 bits of address space,
but the memory device further restricts the range by declaring its
"off" argument as an int! Any reason why this shouldn't be an unsigned?
Its use (at least in the case of real memory) is to pass it to i386_btop
which expects an unsigned.
The relation with the current topic is that PCI BIOS like to allocate
memory resources at the very end of the address space, so to map some
memory on a PCI card (at say 0xff9ff000) all 32 bits are needed.
TIA
Gmo.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3455B267.FBC7DD67>