On Wed, Mar 05, 2014 at 06:22:47AM -0700, Ian Lepore wrote: > On Wed, 2014-03-05 at 13:54 +0200, Konstantin Belousov wrote: > > On Sun, Feb 23, 2014 at 10:52:48PM +0000, Ian Lepore wrote: > > > Author: ian > > > Date: Sun Feb 23 22:52:48 2014 > > > New Revision: 262411 > > > URL: http://svnweb.freebsd.org/changeset/base/262411 > > > > > > Log: > > > If the L2 cache type is PIPT, pass a physical address for a flush. > > > > > > While this is technically more correct, I don't think it much matters, > > > because the only thing in the tree that calls cpu_flush_dcache() is > > > md(4) > > > and I'm > 99% sure it's bogus that it does so; md has no ability to do > > > anything that can perturb data cache coherency. > > > > Yes, md(4) does not break data cache coherency, but I think that > > Marcel added the flush to ensure instruction cache coherency. The > > intent was to ensure that harward-architecture machines would > > see up-to-date memory content when fetching instructions after > > read on md(4). > > Oh. If that's necessary on ia64, it seems like ia64/elf_machdep.c would > be the place to do the flush.
I am not sure about ia64, it was needed for PowerPC, I think. The issue is not limited to the module loads, so elf_machdep.c cannot solve the problem.
pgpwfKDPNOVUc.pgp
Description: PGP signature
