John Dennis writes:
>
> I just received information from HP (thank you Bjorn Helgaas) that the
> memory attribute does not direct access between RAM and IO, I was in
> error. But what is critical is that the EFI MDT (Memory Descriptor
> Table?) which is set up at boot time is the arbiter of which memory
> attributes are used for various memory regions. User space mappings that
> try to force cached vs. non-cached accesses are inappropriate, its not
> their decision, rather it must be consistent with the EFI table which is
> set up at boot time. There is a kernel patch that ignores the user
> request for cached vs. uncached mappings and instead (indirectly)
> consults the EFI MDT such that the memory attribute field in the TLB is
> consistent with how that memory is referenced in the system, as
> determined by the firmware (EFI). Beta RH kernel's were missing this
> patch that had been present in earlier kernels. Bjorn tells me that with
> the patch applied no changes need to be made to X for proper operation
> and that the patch is in the upstream kernel sources.
John,
thanks for following up on this. Does this patch also take care of
the SlowCopy() access to the VGA framebuffer memory at 0xa0000?
>
> FYI, the patch follows for those interested, note that O_SYNC is no
> longer used as a trigger for non-cached access.
>
I have dropped the O_SYNC from open("/dev/mem") for all platforms
a while ago. However on IA64 we pass MAP_NONCACHED or
MAP_WRITECOMBINED to mmap() depending on the type of region.
I assume we don't need this any more, either.
Now, one question remains: does the EFI MDT distingquish between
(cacheable) framebuffer memory and MMIO registers which should
neither be cached nor set WC?
Uncached framebuffer memory doesn't cause failures but gives a huge
performance penalty.
Egbert.
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
