on 29/07/2010 23:02 Sergey Babkin said the following: > Jul 29, 2010 12:58:07 PM, a...@icyb.net.ua wrote: > >> on 29/07/2010 19:13 Andriy Gapon said the following: >>> on 29/07/2010 17:13 Alexander Fiveg said the following: >> In fact I have a suspicion that the problem might have to do with multiple >> mappings of the shared pages, but far from sure... >> Take a look at Intel® 64 and IA-32 Architectures Software Developer’s Manual >> Volume 3A - System Programming Guide, Part 1; Chapter 11.12.4 Programming >> the PAT; >> starting at the following words: >> «The PAT allows any memory type to be specified in the page tables, and >> therefore >> it is possible to have a single physical page mapped to two or more different >> linear addresses, each with different memory types. Intel does not support >> this >> practice...» > > My guess would be that the memory type is not marked as DMA-capable. AFAIK > the Intel CPUs > do the hardware snooping on the physical addresses, so they have no coherency > issues benween > themselves. However if a DMA writer changes the memory, this I think does not > get normally > propagated to the front-side bus, and the CPUs would not see it. You may need > to either > explicitly flush the CPU cache before accessing these pages or mark them as > non-cacheable.
My guess was approximately the same - if one mapping is done in kernel for DMA purposes, then the memory type is, most likely, set to uncached. But the userland mapping of the same pages most likely marks the same pages (via different virtual addresses) as cached. Depending on the hardware and on what mappings were used on a particular CPU (core) to access that memory, there could be differences in interaction with DMA. -- Andriy Gapon _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
