On Thu, Jan 17, 2008 at 10:13:08PM +0100, Ingo Molnar wrote:
quoted text
> 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).

But then, this will cause an attribute conflicit. Old one was specifying
WB in PAT (ioremap with noflags) and the new ioremap specifies UC.

As Linus mentioned, main problem is to figure out the correct attribute
for ioremap() which doesn't specify the actual attribute to be used.

One mechanism to fix the issue generically (somewhat atleast) is to use
MTRR's and figure out the default MTRR attribute for that physical address
and use it for ioremap().

quoted text
> 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.

In this scenario, ACPI is using ioremap() leaving some dangling references.
Venki is looking to fix this code. Getting the attribute for MTRR
for ioremap noflags, might solve some of these issues aswell. Will look into
this.

thanks,
suresh
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/