* Andreas Herrmann3 <andreas.herrmann3@amd.com> wrote:
ah, nice!
but in general we must be robust enough in this case and just degrade
any overlapping page to UC (and emit a warning perhaps) - instead of
failing the ioremap and thus failing the driver (and the bootup).
Does my third patch (which falls back to UC in case of attribute
conflicts, also attached below) instead of your ioremap_nocache() patch
solve your bootup problem too?
while ACPI should not hurt too much from using UC mappings, we should
still solve this intelligently and only use UC when needed. (Sane system
makers with a sane layout of IO areas and BIOS areas should not be
punished with UC overhead.)
no, there should be no such need. There can be "mapping leaks", in that
the mapped object is not unmapped. There's detection code in today's
x86.git that should report something like this if it occurs:
Debug warning: early ioremap leak of 1 areas detected.
please boot with early_ioremap_debug and report the dmesg.
------------[ cut here ]------------
WARNING: at arch/x86/mm/ioremap_32.c:346 ()
but i have not seen this message in your boot log. Could you boot with
early_ioremap_debug and send us the dmesg - i'm curious which ACPI
tables are actively mapped while those devices are initialized.
Ingo
-------------->
Subject: x86: patches/pat-conflict-fixup.patch
From: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/x86/mm/pat.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
Index: linux-x86.q/arch/x86/mm/pat.c
===================================================================
--- linux-x86.q.orig/arch/x86/mm/pat.c
+++ linux-x86.q/arch/x86/mm/pat.c
@@ -174,7 +174,12 @@ int reserve_mattr(u64 start, u64 end, un
current->comm, current->pid,
start, end,
cattr_name(attr), cattr_name(ml->attr));
- err = -EBUSY;
+ /*
+ * Force UC on a conflict:
+ */
+ ma->attr = _PAGE_UC;
+ if (*fattr)
+ *fattr = _PAGE_UC;
break;
}
} else if (ml->start >= end) {
--
