note that full PAT (where in essence Linux takes over control of the
cache attributes via PTEs, instead of relying on the BIOS initialized
MTRRs alone) you should only get with -mm or with x86.git applied.
I.e. x86 PAT might explain any -mm issue but not the upstream -git
issue.
In upstream -git we dont have the second wave of the PAT changes applied
yet (the /dev/mem bits) so CONFIG_X86_PAT is not yet activated. (it's
only safe to enable if we have all the changes together and perfectly
control all cache attributes in the system)
i.e. PAT complications here would not happen in form of real cache
attribute conflicts [i.e. the lockups and corruptions cannot be due to
that] - but as side-effects to other code it changes.
and most of the PAT failures we ever saw had different patterns anyway:
the leading failure was API rejections and hence non-working Xorg or
non-working ioremap() in certain drivers. The worst-case scenario, early
in the PAT code's cycle, was a spontaneous triple fault - months ago.
the basis for the PAT changes was the hardening of the CPA code and its
general use for everything (such as DEBUG_PAGEALLOC). And much of that
happened and was finished in v2.6.25. Nothing conceptually new really
happened there - and even where we touched the code in .26 it happened
long ago and would have surfaced by now.
... but ... nothing can be excluded.
Ingo
--
