On Fri, Sep 4, 2009 at 10:07 AM, Rudolf Marekr.marek@assembler.cz wrote:
I think the only proper way is to do type1 and maybe some locking is necessary.
but our thread subject is "unstable fam10h". Given that fam10h is the problem, and that it supports MMCONF, why not make new versions of the functions for processors that have MMCONF and use them on those processors?
We've never seen this kind of problem on K8 AFAIK. We can continue to use the old functions on those old CPUs.
So, what I'm trying to say: - we have a problem on fam10h - it seems to be a non-smp-safe function doing a config cycle - there are two ways to eliminate the problem o write a fam10 version of that function that will use MMCONF (will work on all later CPUs) o modify old function by adding a lock (i.e. stick with legacy mechanism for older CPUs)
I just can't see a good reason to stick with the type 1 access when the fam10h and, presumably all later families, will support MMCONF. The cf8/cfc is a 15-year-old idea (at least) that predates smp and multicore. We should be trying to eliminate that old mechanism whenever we can (at least it seems that way to me). It is the cf8/cfc mechanism that is the problem, not the lack of locking.
ron